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 article is just a bit too techie for me.. so whats the catch with this new stuff?
will it help some more device manufacturers make "drivers" for linux?
That's why most people should wait for vendors to put out their 2.6 distros.
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).
Don't worry about it, it's just a message indicating that some module in your kernel is not GPL. I'm using Linuxant's DriverLoader, it taints the kernel too of course. Still works beautifully though ;)
Any technology distinguishable from magic, is insufficiently advanced.
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...
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
I've used 2.6 on my desktop since the 2.6.0 test series.
But on my Thinkpad T20 notebook... try getting 2.6 to work nicely with APM, PCMCIA and ALSA sound with the power suspend feature. Yikes! You have to turn off yenta (PCMCIA) to get into suspend and rmmod and re-modprobe ALSA after suspend to get your sound back. I tried working with the person involved with APM but I ran out of steam when I needed to edit a bunch of code in the kernel code.
2.4 works fine.
Ummm WTF are you talking about? The Win32s are FILLED with functions that only work on a specific platforms or are buggy on ceartin platforms making them unreliable. Its only plain vanilla applications that work on any platform -- and you'll find alot of code in there that says if(WINDOWS_VERSION == 98) {} elif (WINDOWS_VERSION == 2000) -- thats not really cross platform compatibility.
Religion is a gateway psychosis. -- Dave Foley
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
Start with the CONFIG_EMBEDDED option - it allows you to excise a significant amnount of stuff from the kernel image that would otherwise remain unused. If you want more savings, there is a tinykernel tree somewhere that has patches which allows you to remove even more stuff. IIRC the kernels built from this tree can comfortably run with as little as 4MB of RAM.
SCREW THE ADS! http://adblock.mozdev.org/ Proud user of teh Fox of Fire - Registered Linux User #289618
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...
Windows 9x/Me drivers don't work at all on Windows XP. What the hell are you smoking?
EXEs are completely different from drivers, and drivers do NOT migrate from 9x to NT kernels.
Vote for global prefs bug
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.
That's not true at all. Any interested party with the knowhow can download the kernel source, fix up an obsolete driver, and send a patch in.
What's that? It doesn't work when you want to keep your sourcecode private and out of the hands of the developers? Fine, but don't expect help porting, or crufty workarounds to maintain the outdated interface you use.
One of the benefits of open-source is that you don't have to put so much work into maintaining things. If a company open-sourced their drivers and their products were used by more than just a few people, they wouldn't have to worry about maintenance.
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.)
libc issues were resolved a long, long time ago.
Still, I think it's a testament to Microsoft that an .EXE can run under Windows 95, 98, 2K and XP and most of the time
Hang about, we're talking about device drivers, not applications. It's a completely different ball-game.
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/
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.
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.
Windows 95 OSR2 had a usb patch available from Microsoft. The file was called usbsupp.exe I think.
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.
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
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.
You do have CPU microcode updates from Intel, and corresponding Linux code to facilitate uploading the code to the CPU : Microcode.
This microcode is not easily hackable (at least I hope so), and most certainly is not open source.
..[besides that its mildy OT].. /boot called config-2.4.x or 2.4.x.config
you will maybe get your system up faster if you cheat [cheesily] and grab the config
from your currently running kernel to start from, provided you have a relatively late
model 2.4.x || >.
its the file in most distros thats sitting in
[not really using more than RH or Deb these days, so im sure there are other places/names].
if you get a working kernel image for 2.6, go back and trim/add options... at least at that point its academic.
- yummy rootbeer.
But that's not the point, you are totally sidestepping the issue.
The OP says win32 is so stable huge amounts of applications and drivers are binary-forward compatible.
This is simply false. My most recent problem with this was a card reader that stated it worked with SE/98, XP and 2K, yet did not work with 2K. Had to go to the site and download the updated driver.
I don't mind doing that, just making the point that the original claim of extensive forward-binary compatibility, at the application and driver level, on the win32 platform, is fairly specious and entirely dependent on the software package under consideration.
Linux probaby doesn't have as much compatibility, but it's not as black and white as the you Windows Zealots try and make it.
I compiled 2.4.24 on a P166MMX today with 48MB ram running knoppix with a hdd swap partition, it only took about an hour, not bad really...
An eye for an eye... leaves the whole world blind.
The 'tainted' message has no influence on the working of your system... So users can indeed do anything they want with it.
Its just a convinient way for developpers to say they don't want anything to do with it.
Jeroen
Secure messaging: http://quickmsg.vreeken.net/
At my last job, we had to get rid of a perfectly good Lexmark inkjet printer because the driver wouldn't work with Win XP, and the company was no longer developing new drivers for it. Ironically, I think there was a reverse-engineered Linux driver available (switching to Linux was NOT an option, unfortunately).
Almost all Linux applications work just fine under different kernels. Device drivers are a different story, though. I don't think Linux is much better or worse than Windows in this regard.
Yes, Linus is against binary-only modules. He also states that he will not put a mechanism in place to make it easier for programmers of binary-only modules.
But, the kernel is released under the GPL, he can't stop you from writing an ABI that allows you to do this. So, while he doesn't want do the work for you, he gives you the freedom to do it if you wish. I don't see how he's inconsistent with the principles of free software. He just doesn't want to do it, nor does he have to.
If jane_hacker can't roll her own kernel, that's not Linus' problem. He gives you the kernel, what you want or are able to do with it is your problem, not his.
Maybe if you offered Linus (or somebody else with the skills) some money to write code that creates a standard ABI to make binary-only modules work, some work would be done on it.
As a final note, Linus started the kernel, it's only fair that he should be in control. If you don't like his level of control, then the GPL gives you the freedom to fork off the code and do with it as you will, as long as you release the source to the changes.
-- Joe
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
Unless you're really desperate for performance, xv is very comparable. What kind of system are you running, and at what percentage load when playing movies.
:-( I'm trying to do up a userspace app that will let me send X10 commands to my PowerLinc USB based on the code in the driver.
The only reason *I*'m not using 2.6 is that the unified Linux X10 driver (wish) has not been ported to 2.6, and apparently requires significant work. Everyone using Linux in an X10 environment is apparently sorry-out-of-luck at the moment.
May we never see th
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
You misunderstand. This is actually not a message meant for end-users. End-users should be using nice little modules that behave properly. The NVidia-kernel at least used to give off the tainted message before, but it STILL was inserted. I haven't seen this change.
This is a help for developers writing non-GPL-modules to make sure they are nice and legal. If you as a module writer writes and distributes binary modules, this makes it clear to you whether you are doing something illegal or not. If you are distributing binary-only modules, then some things are just not available to you.