Slashdot Mirror
Migrating Device Drivers to the 2.6 Kernel
An anonymous reader writes "While it's all well and good to find out how to upgrade your kernel to 2.6, as this recent /. story pointed out, developers, especially device driver developers, might be more interested in the kernel's new device driver model. Over at Linux Devices, there's a new article on Migrating device drivers to Linux kernel 2.6. The short version: That little ole Hello, World! kernel module is a heckuva lot more complicated than it used to be."
Why did it take so long? I just upgraded all four of my boxes last night. It took five hours to upgrade them all.
/usr/src/linux-2.6.2 ... set options and save /boot/vmlinux-1.krnl
emerge development-sources
cd
make menuconfig
make && make modules_install && cp arch/i386/boot/bzImage
reboot
How hard is that? Are you running a 486 or something? Compiling took under 30 mintes on my 350MHz box.
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
Linux 2.6 really is the best thing since, erm, sliced bread. I've been helping my Linux friends install it on their machines this week, and the difference is rather noticable, to say the least. Hopefully it'll get in place across all the main distros pretty soon and the upgrade path will be easier for those who are afraid of recompiling for themselves (i.e. the vast majority if we want more Linux-on-the-Desktop use).
One of my biggest problems with the current driver model is the poor-ish support for loading drivers across minor revisions. I prefer GPL, and agree with a lot of the idealogical reasons behind Free and open source software. Companies, OTOH, do not. We need companies to write device drivers, since the complexity of something like an nVidia GeForce GPU is simply too much for a small team of people to reverse engineer.
One of the biggest problems at the moment is not being able to go to nVidia's website, download a precompiled binary module for your arch and load it into the kernel. Equally drivers off of a manufacturer's floppy or CD-ROM need to work this way too. Unfortunately it seemed that with Kernel 2.4, even a 0.0.1 difference in version number could mess things up and require recompilation. Has this been improved in 2.6?
I think that this is the level of compatibility that needs to be achieved before we see more widespread support by the HW manufacturers. It seems like the guys over a freedesktop.org will have their work on a graphical driver loading system in place quite soon, so this part of the deal is essentially solved.
The parent is not a troll. I've had a lot of problems with the 2.6 kernel CRASHING upon bootup. Unfortunately, the kernel panic message is too long and not enough of the error message is left on the screen is useful enough to figure out where the problem occurred. The problem usually goes away when I go back through menuconfig and turn off all drivers that I know I won't be using. I'm not sure why 2.6 is much more finnicky about configging it than 2.4.x, was it the low latency modifications? Running the kernel with pre-emptive threads? I don't know. Also, 2.6 SCREWS with the way some drivers behave, namely /dev/psaux (which now, unhelpfully, mixes not only PS/2 mouse events with events from, say, a WACOM tablet) and the USB event subsystem which now ennumerates non-USB devices. Good luck getting XFree86 to access your input devices propertly on 2.6!
Would it be possible to have some sort of cross-platform driver language like Java for device divers? That would be really cool because each platform could have its own VM and the same driver would run on Windows, Linux (all kernels), Mac, etc.
ls -l arch/i386/boot/bzImage
1472687 arch/i386/boot/bzImage
I've kept my kernel config to the absolute minimum and made everything as modular as possible. On 2.4.24 the bzImage was only 1056223 bytes, now it's jumped by 400kBytes.
Has anyone any useful tips for cutting the "bloat"?
Scroogle
If the .exe is statically linked perhaps, otherwise, you're going to have all kinds of library problems when moving the sam app between win 95, win 98, win 2k, and win XP. Keep in mind for earlier OSes in the chain, apps frequently shipped with their own shared libraries causing other apps or even the whole system to break.
I'm not sure about device drivers for Windows, but I would be suprised if there weren't problems with using win 95/98 device drivers with win XP.
Not to say that updading linux is painfree, I just think you're overstating the case for microsoft products. C library upgrades aren't a big deal, most distros contain compatibility libraries for older versions. There were some serious issues with libc upgrades, but that was years ago. It's really a non-issue in my development experience. Other libraries cause more headaches than libc.
Attn Mods: How a post that intends to comment on the strain imposed on developers for linux kernel and libc upgrades and also says this "it's been a long time since I've been active in Linux development" can get modded up to +5 informative is beyond me. Insightful or perhaps inciteful, but not informative.
XML causes global warming.
Would you people also be willing to put up with a closed-source Linux kernel, if some CPU manufacturer decided tomorrow that they didn't want to release the specs for their instruction set, and said the only way you could write a kernel would be if you submitted to an NDA? Why is it that things like Wireless Network drivers or video drivers are the ONLY thing subject to this kind of thing?
Not hard at all ... of course, you won't be running the new kernel when you reboot.
/usr/src && make buildworld && make buildkernel && make installkernel && make installworld'
I still prefer:
'cd
Having done driver development for both Windows and Linux, each OS has their plus's and minus's:
.c file pretty much does it all
Windows good:
With some effort, my USB networking driver is binary compatible with Win98 through WinXP. This is really awesome because I don't have to spend a lot of time re-writing and re-compiling drivers. For the customer, it just works.
Windows bad:
Writing drivers for Windows is like working on your car with the hood welded shut with only a 12-inch diameter hole cut into the top. Driver writing is EXTREMELY complex on Windows. MS tries to hide everything from you with convoluted callbacks and opaque data structures. My first USB networking driver took me two months just to get a basic skeleton running. On Linux, the same driver took me two weeks to completely finish and I'd never written a driver for Linux before.
Linux good:
Driver writing is soooo much easier and intuitive (at least for the 2.2/2.4 kernels). One
Linux bad:
Having to recompile for every kernel just bites. I understand and agree with Linus's reasoning for encouraging open source driver development. Alas, the company I work for doesn't.
So overall, I'd say the Linux driver model is superior for developers but ease of use is what drives mass-adoption of a product. I guess it just depends on your target audience. Our Linux user base, while vocal, is insignficant compared to Windows and even Mac so guess which driver I spend most of my time working on?
X
I just had to port a kernel module I wrote for my employer a year or so ago. Told my boss it'd probably take a week. Instead it took me 15 minutes. I grabbed a Makefile from an example, compiled, noticed that the return type for interrupt handlers had changed, fixed that, done. Thanks to the kernel developers out there for making it so easy!
I have a driver for an ethernet card that I had to compile - the source came on a disk with the card. Once it was compiled I loaded it with "insmod" and it worked. To get it to come up automatically at boot time, I just created the "rc.modules" file with an "insmod" line in it and everything is fine. This is running on a 2.2 kernel (yes, 2.2, RedHat 7.0), and I really don't have much need to upgrade.
Now, how is this going to work for 2.6? First of all, NO F*CKING WAY would I even think of re-compiling the kernel - the machine is 180mHz (yes, that's 0.18gHz if you like that better!) and it would take a week. Compiling a small driver is fine, but nothing really big. It can stay a module with insmod forever and that's fine.
Second, I am not developing the driver, just using what the manufacturer provided, and I don't really want to figure out how to change it.
So, the article didn't really say, will there be any sort of "grandfathering" to allow you to just continue to "insmod" older drivers? Some sort of compatibility mode?
If not, it looks like there may be some pretty severe barriers to upgrading to 2.6, and really good reason to keep work going on 2.4 or 2.2 - minor fixes, security, etc., for those who don't need the grief of a major upgrade.
Teen Angel - a Ghost Story
It is just a matter of how well we support it. Currently, nothing. The result, we end up using windows drivers. Examples are ndis and ntfs.sys. This trend will continue.
An alternative, come up with a standard API for each device type (video, ethernet, scsi, etc) Then create a wrapper between the internal API and the spec. Internal API changes, port the wrapper. If we can do it with windows drivers we should be able to come up with something more efficient and less hackish.
Original API aged poorly? Design a new one and implement the wrapper as another driver. Both can coexist.
I see no reason Linus would have a problem with this from a tech perspective. It's just another driver. GPL drivers could avoid the wrapper and would remain prefered.
Parallel implementation with a BSD would avoid most of the licensing issues.
Who the hell wrote that? Why was the patch accepted? What part of "I'm in control of my own computer" was too confusing for this guy to understand? Just to make it absolutely perfectly clear, when I say 'insmod foo.o' I expect foo.o to be loaded into the kernel. The only reason why it shouldn't is if there is a dependancy that would make it not work (but I expect to be able to insmod -f throught that). I do not want my kernel checking the license of foo.o and determining whether or not I am allowed to insert the module.
Even if you make the claim that you have the right to refuse someone who doesn't GPL their module to link to your module, that has absolutely nothing to do with me. It's a matter between you and the guy who isn't GPLing his module. Me, as a user, are free to link any two pieces of software together that I like. You have absolutely no legal claim to stop me. It's my computer. I thought this all was pretty obvious and it was only the stupid corporations that think they can control our lives who write software to stop me doing what I want to do with my computer, now I'm finding linux kernel developers are doing the same.
If you want to set a "tainted" flag, if you want to show me a warning, that's just fine, go right ahead, but don't ever stop me from doing what I want with my computer. Now I'm going off to hack my kernel to remove this insanity. Who knows, I might post a patch on the kernel mailing list.
How we know is more important than what we know.
Let's say, e.g. Munich or IBM or whatnot finds it's time to make a purchase. Requirements: Linux compatible.
Once you can attribute a significant number of "Lost sales" to "Lack of Linux compatibility", PHBs will demand that it happens. They couldn't care less about the hobbyist, but if large corporations starts running Linux desktops, as is very likely for basic office tasks, they sure as hell care. And so every peripheral used by corporations, which bleed over pretty damn well into consumer peripherals, then consumers starts demanding the same...
And then the engineers will go "Gah, this binary API is changing *all* the time. Can't we simply release a GPL driver and be done with it?" And then, after a little talk with legal, and probably the PHB again, hopefully it'll happen. Not to mention they can take the GPL code of any similar driver, and copy-paste (with appropriate copyright headers and all, of course) into their own.
All Linus has to do is to stay strong on this matter - once Linux is past a reasonably critical mass, I suspect it won't really be much of an issue. The strongholds will be where there is no real alternative, mostly GPUs. But it might also be that Linux is hardly used much by heavy gamers - so they don't see much lost sales at all yet.
I suspect that it will go the other way. Most drivers will become open, and a few will remain closed. Perhaps in the end, if and when Linux is popular enough, they will simply close the kernel to any binary modules, and whichever has the "weaker" OSS drivers would face lost sales. I sure think it's easier to hit companies where it hurts (in their wallet) than getting Linus to change his ideological viewpoint. We're just not there yet.
Kjella
Live today, because you never know what tomorrow brings
Really? I use GRUB, which doesn't need me to reload LILO, so all I have to do is drop the kernel file where there's a grub.conf entry and it boots.
Ahh the joys of a two-stage bootloader.
BTW, I run two entries in GRUB, unik-mpd1 and unik-mpd2, unik-mpd2 is the 'safe' kernel, when I'm happy with 2.6 I'll copy it to unik-mpd2 and run newer kernels in unik-mpd1.
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
If the .exe is statically linked perhaps, otherwise, you're going to have all kinds of library problems when moving the sam app between win 95, win 98, win 2k, and win XP.
That's funny, I do it all the time with no such problems. You do have to use GetProcAddr if you want to use features that don't exist in the older versions, but that's far from difficult. Sometimes there'll be some subtil change in behavior in things like common dialogs, but nothing earthshattering.
Microsoft goes to a LOT of trouble to make sure existing applications still work on a new version of Windows, because if you DID have to recompile all your apps, you'd be screwed. And then no one would upgrade.
Drivers are almost certainly a different story of course, especially since they changed driver architectures completely in there. Still, they can't go breaking everything too often or, once again, you're screwed if you need to recompile it. Especially if you're using expensive hardware from a company that has since gone out of business.
That's one of those downsides of closed source, you have to maintain binary compatibility.
..there is still benefit from shared libraries, if you ever have more than one instance of the app running at a time.
A small advantage of saving a couple hunded k for each instance offset against the complications of installing a new DSO and having to maintain minor and major versions of that DSO (& breaking other applications which may come to use your DSO if you don't maintain the ABI & API)
I'll take the statically linked binary and the extra couple-hundred k overhead thanks. There is a time and a place for DSOs and 90% of the time on Linux it is the wrong time and place.