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."
The build process is substantially different. Actually, it's simpler, provided you have a Linux source tree handy. But you can't develop your kernel modules just anywhere anymore.
Actually, the license macro isn't even necessary, 2.6 is just bitchier about kernel taints.
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).
Sorry, but it's not gonna happen. Linus has repeatedly stated that he will never modify the internal APIs of the kernel to make the maintainership of binary-only modules easier for hardware manufacturers. While this attitude may seem unfair and self-serving, it makes sense, and is not likely to change.
Right now 3D graphics drivers for ATi and NVIDIA cards are the only sticking point in hardware support IMO. Just about every other major component has Linux support, if you do careful research before buying.
SCREW THE ADS! http://adblock.mozdev.org/ Proud user of teh Fox of Fire - Registered Linux User #289618
Sorry, but what you envision is never going to pass. Linus has repeatedly stated that he will not permit the modification of the Linux kernel source in order to cater to the maintainers of binary-only modules. If they refuse to *PL their code, then they must shoulder the burden of maintainership until such time that they do decide to *PL it.
It would be nice if the code allowed this, but since it doesn't, all we can do is carefully research the support and drivers that do exist and are available for the latest and greatest hardware, before we buy them.
SCREW THE ADS! http://adblock.mozdev.org/ Proud user of teh Fox of Fire - Registered Linux User #289618
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/
The problem is not the language but the interface to the kernel. The C language, which a lot of drivers are written in, is very portable but you still cannot easily take a driver from Windows XP and port it to Linux, because the driver has to provide and call different functions in Windows vs Linux. What would be required is a standardized API for device drivers but that is (IMHO) not likely to happen soon. There are some however some interesting wrappers for using Windows WLAN drivers under Linux, maybe it would be possible to extend that to other kinds of drivers.
I gotta just reinforce the fact that the new kbuild system makes compiling kernels outside of the build tree much easier.
/lib/modules/.../build to the kernel source, further with kbuild, it handles all the dependencies and symbols, etc.
/usr/src/linux-2.6.2 SUBDIRS=$PWD modules
First of all, there's now a symbolic link from
Basically, compiling a module outside of the tree in the old 2.4.x was difficult and if you were using modversions, almost impossible - you need to have the kernel source and kernel configuration - its necessary anyways. Now, all I need to do is
make -C
and voila, kbuild handles everything for me.
fnord.
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?