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."
how is the extra added line of MODULE_LICENCE("x"); make the simple sided 2.6 kernel module substantially more complicated?
.
fully-functional ATI drivers (with newbie-proof installer), then I for one welcome our complicated-new-kernel overlords.
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
Supposedly the third edition of Linux Device Drivers will be released soon, and will be geared towards 2.6 development (obviously). Anyone who's ever wanted/needed to do linux module programming should definitely take a look at this book, it's basically *the* reference.
LWN has some documentation on this for some time now: http://lwn.net/Articles/driver-porting/
The only difference in the skeleton modules described in the article is a MODULE_LICENSE("GPL"); and a "return 0;".
Breathtakingly difficult ! In fact, the only 'hard' part seems to be changing how (if at all) your module interacts with other kernel components ! If you wrote a module that utilises these aspects of the kernel, moving to a new API would not be that difficult.
"I am not bound to please thee with my answers" [William Shakespeare]
There's a 30 article series over at LWN about porting drivers to 2.5/6 with both overview articles (like this hello world one) and specifics (like how the block layer changed).
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!
One of the good things about Microsoft Windows is that is you've written a driver for Windows 98's to the WDM standard, it's still pretty much supported under Windows 2000 and Windows XP. That is to say that there isn't a lot of retrofitting that needs to be done to get a legacy driver working under the latest Microsoft OS.
.EXE can run under Windows 95, 98, 2K and XP and most of the time, it's just going to work. You can't say the same about versions of Linux.
Linux, on the other hand, seems to think it's OK to make developers retrofit their code when they don't like the ad hoc design that the OS contributors came up with. This coupled with issues (questions?) of compatibility with things like the GNU C runtime libraries really must make it frustrating to do any serious development on Linux. (Feel free to rebut--it's been a long time since I've been active in Linux development.)
Still, I think it's a testament to Microsoft that an
Karma: Excellent Birds (mostly as a result of listening to Laurie Anderson)
The "tainted" message just means that the module does not claim to be GPL. As a practical matter, you can just ignore the "tainted" message. If you are concerned about whether modules are GPL or not, then you may find the message useful.
A dingo ate my sig...
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
Yeah, call me a troll if you wish, but I really do think it is amazing how so many people here are willing to beg and plead on their knees that the Linux kernel developers freeze the driver API so that closed, proprietary-source hardware companies can write closed-source drivers for their favorite wardware device.
So then, let's take it a step further: would you people also be willing to put up with a totally closed-source kernel, and a closed-source C compiler, if the hardware manufacturers demanded it? In that case, why not just use Windows?
Seriously, I fail to understand why you people want to use Linux, only to complain about the lack of hardware support, since the Linux world requires everything to be open source.
Tell me, would you people also be willing to jump off a bridge to get driver support if the hardware manufacturers demanded it?
I do believe Linux (or GNU Linux, if you prefer), as a platform (not just the kernel), would not be as open as it is today if the developers didn't insist on such openness. If you people don't care how open things are, then why bother with Linux?
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?
I suspect about 1 in a 1000 people who read /. really understand what the article is talking about
Who cares, that's the usual percentage of posters, who read the articles at all. Can't answer the rest of your reply - lost interest somewhere in the middle of it. I wanted to give you my 2 cents, but discovered that I'm a bit short on money today, sorry.
No need to do so, check this out: HowTo Upgrade To The 2.6 Kernel And you are not idiots, you just don't RTFM...
The only thing that is difficult is that you have to keep up with the development of the kernel itself.
As for complicated... having had a look at some windows drivers source code and writting my own linux drivers I can say that it is way easier to write a linux driver than a windows driver. (Even if you have to port it to a new major kernel release every few years)
Jeroen
Secure messaging: http://quickmsg.vreeken.net/
Man, I miss the days when people who were interested in technology read Slashdot....
It's like an altair, but with 8 independent 64-bit processors, 32M total L2 cache, 4G total ram, and 8 independent fibre-channel hard drives.
/me shudders at the though of coding with dip switches.
I use a Linux X terminal as a client, but the principal is the same as on an altair.
You can't judge a book by the way it wears its hair.
If you're having problems with input devices, search the LKML archives for Vojtech Pavlik's 2.6 input FAQ (he's the maintainer of the kernel's input system). You can find a list of searchable archives at the LKML home/FAQ page.
Err, I'm feeling generous, here: 2.6 input drivers FAQ ^_^;
You may be confusing the "USB event subsystem" (of which I'm really not sure you're talking about) with the generic input system.
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!
Linux Weekly News also has a great series on driver porting at http://lwn.net/Articles/driver-porting/. It's in the subscription-free area, so go there and have a look at it.
Common situation before 2.4:
1) User loads proprietary module
2) Kernel goes unstable and crashes like hell
3) User responsibly decides to post OOPS and bug report to LKML
4) Kernel devs groan for the 1000th time and explain that they can't test a problem with an opaque driver
The problem is that a black box piece of code is 'tainting' the kernel. If something goes wrong with that code, you're SOL because you can't look inside the black box. Module licensing forces a closed driver to identify itself as such, and then notes that the kernel is tainted in the OOPS, so if you submit an oops like that then the kernel devs will (quite rightly) say "Don't expect us to fix a problem with a proprietary driver, bug the guy who wrote it".
It's mostly a bug tracking thing for the kernel developers in other words, it doesn't really change how the kernel behaves or what you are or aren't allowed to do with it.
Some kernel developers (me included) don't like the idea of making functions in the kernel available for use by closed source drivers. This way the module loader prevents certain modules from using certain functions.
But the most important is bug reports. If you load a non open module your kernel gets 'tainted' and this is reported in oopses. If you then send this oops to one of the kernel maintainers they can just ignore you. Since you have a piece of unknown code in use in your system they can't do anything usefull anyway.
Jeroen
Secure messaging: http://quickmsg.vreeken.net/
Is anyone able to point me to a module that broke between 2.4 and 2.6 that wasn't fixed with a three line patch? :-(
OpenAFS.
The reason I'm still using 2.4
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.
will it help some more device manufacturers make "drivers" for linux?
New device driver format. Is it good or is it whack?
Basically, the article is explaining that by following certain conventions in the driver code, you allow the kernel a standardized way to load and use the driver.
In other words, if you're going to make third-party Legos, make sure the nubbins on the blocks are the same size and wit the same spacing as the nubbins on Legos, if you want everything to fit together.
The author of the article then inserts a plug for his company's software:
He also explains that in cleaning up driver building for 2.6, somebody forgot that not everybody has write access to a copy of the kernel source, which 2.6 driver building -- whoops -- requires. This is simpler to get around, so long as you've got room for your own writable copy of the kernel source. This will prove annoying for people who build drivers by compiling them on certain *cough* Zaurus *cough* embedded devices (rather than cross-compiling) and who use something like cramfs.
The article then spends a few paragraphs on where the real compatibility problems will be: 2.6 is lot different than 2.4 in a lot of internal processes, so if your driver made assumptions about any of that -- instead of being itself written in a layered way -- you're going to be making a lot of changes.
(Ideally, you should write the driver so that one layer handles communication with linux, one layer handles communication with hardware, and one layer sits between the other two to "translate" and maintain state; this also makes porting the driver -- whether to 2.6 or another operating system altogether, -- far cheaper and easier. Programmer laziness, management short-sightness, or pre-mature optimization may however have driven you to write a monolithic driver.)
Will this help more manufacturers make drivers for linux? Not really. If manufacturers cared about making linux drivers, they'd have already done it for 2.4. If they didn't care to do it for 2.4, they won't care to do it for 2.6.
If you really want more manufacturers to make drivers, you have to do the following: get the phone number for investor relations at the company. Call up and ask them how much market share they've lost by not offering linux drivers, and explain that you're worried about the company's long-term prospects if it continues to ignore this growing market. explain that as a result you're going to be reducing you exposure in the company's stock in favor of their competitors who do offer linux drivers.
(Since most companies are now run by managers whose compensation is based on short-term stock movement, and not long tern company growth, the companies hare increasingly deaf to the needs of customers, but alert to stock speculators and their stock price. Therefore I now recommend calling Investor Relations rather than Customer Relations if you wish to change a company's policies.)
Opinions on the Twiddler2 hand-held keyboard?
Some kernel developers (me included) don't like the idea of making functions in the kernel available for use by closed source drivers. This way the module loader prevents certain modules from using certain functions.
I feel like getting flamed and losing some karma. It's the day after Valentine's anyway, so it's not like I was expecting to be happy anyway.
Why prevent closed source drivers from using certain kernel functions?
Sure, I realize it makes a political point to closed source developers: "your code will remain second-class code until you show us the source", but like a SPEWS blacklist, it does that by annoying innocent third parties in the hopes of getting the third parties to join you in your complaints.
In this case the innocent third parties are the people running linux. So linux users get punished by linux developers for "consorting" with the "enemy's" closed source drivers. Ironically, at the same time, linux is promoted as the OS that allows the user full control over his computer.
If you really believe in the user's right to run his PC as he wishes, let him decide whether or not to buy closed-source hardware.
If you don't, then say so: "I'm giving you the benefit of my code, and I'm not charging for it, but it's not really free, as I expect you to adopt my ideology to use it, and to let me dictate to some degree how you use your PC." That's a valid and defensible stance -- but it's a different stance than is usually professed.
And admit that it's a barrier to wider-spread adoption of linux, and factor it in when asked why more people are not using linux.
Opinions on the Twiddler2 hand-held keyboard?
> Why prevent closed source drivers from using certain kernel functions?
It prevents the kernel maintainers from wasting their time trying to debug a problem that may be caused by a module for which they have no source and no hope of fixing.
Next week on Saturday Night Live:
LINUX USER JIMMY (Played by Horatio Sanz): "I want to use the Yoyodyne USB Blender on my linux box, so I can make margaritas over dial-up SSH!"
KERNEL DEVELOPER (played by Chris Parnell): "If we let the blender driver call kernel_foobar(), it might work flawlessly."
LINUX USER JIMMY: "OK great! Linux r0x0r5!"
KERNEL DEVELOPER (dourly) "But... it some cases, it might fail."
LINUX USER JIMMY: "But it'll usually work? I can't wait to taste those margaritas!"
KERNEL DEVELOPER: "No, Jimmy" (shakes head and sighs) "it will never work, because we don't allow the Yoyodyne driver to call kernel_foobar()." (pause) "It might fail, and we can't allow that to happen. (nods authoritatively, looking Jimmy in the eyes) You understand."
LINUX USER JIMMY: "So I can't make my margaritas if I use linux?"
KERNEL DEVELOPER: "No, Jimmy, you can't. Because we kernel developers know better."
Opinions on the Twiddler2 hand-held keyboard?
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.
you can read Robert M. Love's Linux Kernel Development , authored by the person who brought us kernel pre-emption, and is now working at Ximian/SuSE on kernel-desktop integration. Can you say Utopia ?
Michel
Fedora Project Contribut
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
I would love see linux really catch up to Windows here. Having worked on Windows and Linux drivers I can honestly say that for me, Windows device driver development is much easier. I am comparing writing Windows 2000/XP device drivers with Linux 2.4.x device drivers. Most that I have worked on are networking, storage, or low level bus drivers.
The driver APIs in windows appear to be more stable and documented better. The backwords compatiblity that MS allows in their driver model is great. For example, each time a new feature was added, it was always possible to use the old style for a few revisions. For example, when power managment and plug and play were added in Win2k, MS made sure you could still make a driver without the new calls and things would work. Even their wrapper models for networking (NDIS miniport) and storage (SCSI miniport) easily allow backworks compatibility. NDIS is nicely designed with versioning in the structures so that NDIS can know what version of the API the driver supports and handle it correctly.
The documentation in the DDK help is has improved greatly since the dark NT4 days. MS worked hard to audit the DDK docs and work with the developer community to improve them. These days their isn't much you will find in a header that doesn't have a nice page in the DDK help.
At each Windows Hardware Engineering Conference and also at the new Driver Developer Conferences they go way out of their way to make life easy for driver developers. On the source front, they provide source for sample drivers of almost every kind...even for some currently shipping internals.
The debugger is great. From a GUI or command linux, I can reload drivers over my debugger connection (serial or 1394) on a live system. I can connect to my debugger over TCP and remotely debug it. I can do almost everything I can do in a normal application debugger.
I can get kernel dumps of various types from full memory to 64 kb minidumps. Full memory dumps allow crashes to be totally debugged...much of the guess work is removed when you can see everything that was on the system at the time of death.
They also have great test tools built in. Between Driver Verifier and the Hardware Compatiblity Tests, a massive number of issues can be caught before the driver even gets to system testing.
In the linux world, I have to live with weak kernel debuggers and lack of true memory dumps. In real low level driver for a DMA device, in many cases you don't get the nice happy survivable oops...you get the "I need a damn camera and small console font to capture what stack made it out" oops. Every linux 2.4 device driver book should come with a digital camera for debugging! I heard that 2.6 adds some sort of memory dump...a dump to disk would make post-mortems so much easier. Any one know more about this?
Add to that the constant changes that instantly make documentation outdated and force driver develepers to rewrite with only the new source as their guide. The kernel rev issue is not just a GPL it and recompile...the APIs change and the meanings of status codes change, etc.
Each kernel revision my company supports requires significant work on our end. Even if it was as simple as a recompile and test, the rate of kernels released makes it difficult for developers and system test groups to keep up. It takes a lot to test high end drivers. Weeks can go into a system test plan for a specific revision of the driver with a specific revision of the kernel only to see a newer kernel suddenly become the "new new" thing.
On the test tools front, the world is fragmented with some companies having some certification testing but no true driver certification tests. I would love to see a 2.6 storage driver tester and a 2.6 networking driver tester. Is there anything happening on this front?
-- soldack