| |||||||||||||
That's why I love Linux...That's why I love Linux...Posted Dec 15, 2005 3:19 UTC (Thu) by sbishop (guest, #33061)Parent article: SMP alternatives
The difference between this idea and the way Windows works is incredible. Self-modifying/optimizing code versus "Another processor? Do you have a license for that?" Wow. I've realized recently that Linux often benefits technically from its license. This idea is an example of that. I've seen another example at work, where I maintain a Linux USB driver used internally. It's based off the example USB driver that's included in the Linux kernel code, and it's about 600 lines long. The corresponding example Windows driver that comes with Microsoft's DDK (Driver Development Kit) consists of multiple files and around 8,000 lines total. Why the difference? Because the Linux developers aren't tied to an ABI, or API, for that matter. They can adjust the interface between the kernel and drivers (because they have the source for those too) until they get it right. The Windows driver contains much that really ought to be built-in. A +10x difference in code size--that's huge. And guess which is more than twice as fast than the other? :)
(Log in to post comments)
That's why I love Linux... Posted Dec 15, 2005 10:35 UTC (Thu) by Duncan (guest, #6647) [Link] I'm certainly no MSWormOS fan, and I like your point, but in actuality,from what I've read, MS is one of the better proprietaryware venders in regard to multicore, at least. While the likes of Oracle continue to bill per core, MS has been looking pretty flexible by comparison, saying it will continue to license per CPU, even as the number of cores per CPU begins to climb. As to the USB driver, if it's useful for you, unless you are developing it for as yet unreleased hardware, it's almost certainly going to be useful to others as well. The GPL doesn't require publishing code for internal work, but consider the benefits of either /not/ having to do that internal maintenance, as it's done for you by the kernel crew, or submitting it for kernel inclusion and becoming the maintainer yourself, thus gaining visibility and favorable press throughout the Linux world, /plus/ having a bit of the work still done for you, when someone changes out kernel code you depend on from under you. Of course, you likely have your reasons for not doing so, but come on, you gotta admit such a posting to LWN is just /begging/ someone to ask why you haven't yet made source available! <g> Duncan
That's why I love Linux... Posted Dec 15, 2005 16:18 UTC (Thu) by sbishop (guest, #33061) [Link] Yea, I suppose that I should have seen that coming. :) I work for a manufacturing company. The hardware is a tester that only we'd be interested in. And the driver really isn't far distanced from usb-skeleton.c, so it very interesting either.
That's why I love Linux... Posted Jun 1, 2006 16:41 UTC (Thu) by cventers (guest, #31465) [Link] Is it a tester that no one else on Earth owns? :)
I read that GregKH re-emphasized at the recent FreedomHEC that the kernel
Internal-use kernel code Posted Dec 16, 2005 16:51 UTC (Fri) by giraffedata (subscriber, #1954) [Link] You silently merge the idea of making source code available and of getting it in the kernel.org tree. You also seem to merge, as many people do, the idea of submitting code for inclusion and of that code being included.There's a significant cost to getting code into kernel.org. I myself write lots of kernel code, and while the world is welcome to all of it and much of it is published, I have never attempted to get any of it into kernel.org. First, I'd have to translate it to a coding style I don't like and package it according to some pretty specific rules. Then I'd have to run the gauntlet of some mailing list, probably having to rework the code a few times. Some of that rework would be stuff I don't agree with. Some would be stuff I have no use for. At no point would I have any guarantee my work would result in any code going in. So I suffer the costs of being out of tree (mainly, I can't use the most current kernel.org code), but it beats the cost of getting in tree.
Internal-use kernel code Posted Dec 16, 2005 19:42 UTC (Fri) by Duncan (guest, #6647) [Link] Well, I'm aware of the difference, but didn't go to my usual lengths tospecify it. How come other folks can take shortcuts, but every time I abridge a detail, I get called on it? <g> I suppose it's likely because folks are used to me being so detailed, tho some might be just coincidence. Anyway, yeah, thanks for making the code available, even if it's not targeted at the kernel tree ATM. That's an important right of Free source, too, being able to NOT have to go for merge, if desired, tho because it's Free source, others can take it and go for that merge if they want to, again, another important right. Thanks also for filling in those details. It's quite possible the additional information will be of use to future readers, and I /did/ fail to mention it, so it's good someone came along to fill the gap. =8^) Duncan
|
|||||||||||||