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?
how is the extra added line of MODULE_LICENCE("x"); make the simple sided 2.6 kernel module substantially more complicated?
.
That's why most people should wait for vendors to put out their 2.6 distros.
fully-functional ATI drivers (with newbie-proof installer), then I for one welcome our complicated-new-kernel overlords.
ONE WEEK?!?!?! Its a less-than-15-minutes process the whole thing! Less than 5 minutes flat if you had ever played with 2.5.40+
I just upgraded 2 slackware 9 boxes to 2.6 It was easy. You must be using some odd hardware or are a newbie.
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).
Substatiante your claims rather than making crack jokes. Looks like flamebait to me.
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!
I tried ndiswrapper, I tried some winmodem module (claimed to support 2.6!) - whatever I do, there is no struct_module version, so I get "kernel tainted" message. Anyone knows how to fight this?
I run Gentoo and choosing to run 2.6 hasn't "broken" any of the 2.4 style modules that I use. ALSA still works, my NVidia driver still works (I needed the minion.de mod for a few of the releases). 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?
BBH
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)
Just wondering.
What is this 'Operative System' named Kernel you are talking about. Pfft... Get with the tides nerds! use Linux!
---
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.
Drivers are complicated in Linux. Oh, of course not if they are in the kernel, but prepare for the first drivers that have to be compiled. If you're lucky, all goes well. However, it is very likely that you'll run in version problems (devs like to change headers). Making device driver development more difficult is not really a bright idea, either.
This sig does not contain any SCO code.
..is that mga_vid hasn't been ported yet :/
Outline the process step by step right here on slashdot for us newbie idiots.
People don't exist to serve systems, systems exist to serve people.
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
IMNSHO something like FORTH would perhaps be more suited to this. It's an interesting concept, though probably one that won't be implemented in a world where performance is crucial (for things like video cards) or vendors cut corners and tax the CPU (for things like modems).
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
The only case where I really cared about driver compatibility was once where the I/O card we had in the lab was distributed with DOS drivers (the company since disappeared). Unfortunately, these particular drivers only worked under Win98 and older - all poorly supported versions of Windows. As a result, we ended up having to buy all new cards in order to upgrade. At least if we had the source we could have tried porting the drivers...
.EXE running under multiple versions of Windows. I can download a large number of *nix programs, compile, and run under numerous flavors of Linux, BSD, and other OS's. In fact, most are already precompiled for the favorite distros. Office suites, window managers, scientific apps, LaTeX... its all available.
Whoopee about an
As far as development goes, my limited experience has found Linux to be much nicer. Under Windows, you have to download the whole DirectX SDK (100s of MBs) just to capture frames from a webcam. This also requires the use of VisualC++. Under Linux, simply compile the apropriate USB modules and you're ready to go.
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?
The blah-blah-blah overlords jokes are lamer than hot grits and Star Wars princess jokes.
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?
You lost me on step 1:
-bash: emerge: command not found
Oh, silly me, here we go:
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
Nuts, a minimalistic J2EE JCA adapter or what not is ten times that complex. God, I hate J2EE. I made a "Hello World" example using doclets and all that shit in Eclipse and it generated 27 f iles. TWENTY SEVEN FILES for Hello World!
"Broke" it? Do you not use a bootloader to roll back "just in case"?
DrPascal: Not the language, the mathematician.
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.
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
..[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.
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.
#include img src="/files/misc/lt.gif">linux/module.h>e img src="/files/misc/lt.gif">linux/config.h>e img src="/files/misc/lt.gif">linux/init.h>
:)<br>
#includ
#includ
Wo w - now modules come with a little icon built into the module? All this gui stuff is going way too far
Don't they know about < on that site anyway?
Get your own free personal location tracker
Not hard at all ... of course, you won't be running the new kernel when you reboot.
Why not??
I'll give you a hint: The whole world doesn't use LILO you fuckwit.
To be fair, slackware 9 is 2.6 ready - you shouldn't have to do much more than plug in the kernel.
ݼ)s$æúßðíÊ'öX'îò5^àûßQç£
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.
Yeah I know its already +5 Informative.
It can't be overstated how good the LWN resource is though. Awesome.
No, I did not read the f***ing article!
The next release of Mandrake Linux will feature the 2.6 kernel. They are at Beta 2 of Mandrake 10 right now. Fedora Core Test 2 is specifically for testing the 26 kernel, among other things.
perl -e 'print $i=pack(c5, (41*2), sqrt(7056), (unpack(c,H)-2), oct(115), 10)'
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
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
Drivers are complicated in Linux.
If you're claiming this, you've never been involved with Windows driver development. Windows driver development is far, far worse.
May we never see th
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
I would agree with that to a point. Slackware 9.1 is really ready, 9.0 is kinda sorta ready.
mine can still heat a two-car garage.
You can't judge a book by the way it wears its hair.
These people can't even figure out <, but they feel that they're qualified to comment on linux module coding?
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
Indeed. It was interesting to note how this thread http://developers.slashdot.org/comments.pl?sid=969 45&cid=8288177 was modded down as flamebait and troll and whatever. Thanks to 14-year old moderators who have no clue!
Hi!
I'd like to port a Agere softmodem driver to 2.6. There's a binary-only module, but also a small interface to some 2.4 functions, like some PCI functions. Unfortunately, those functions seem to be gone in 2.6. Is there any wrapper to emulate the 2.4 functions (like the one to get an ID etc).
TIA,
Andreas
...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.
Riiight. So by "done", you mean "compiled". Classic.
#include img src="/files/misc/lt.gif">linux/module.h>
This makes us visually oriented people cheer! No more plain text in code, now images!
When can we see flash intros in `make modules`?
About half way down the article, it says:
e <img src="/files/misc/lt.gif">linux/config.h>e <img src="/files/misc/lt.gif">linux/init.h>
:-)
A generic template for a minimal 2.6 device driver would therefore be the following:
#include <img src="/files/misc/lt.gif">linux/module.h>
#includ
#includ
When did gcc get HTML support?
tes
Not that these are much use to anyone here, but the 2.4.xx "Hello World" kernel module can be found here and an updated for 2.6.x can be found here.
Disclaimer, I have not compiled a "hello world" module since 2.2, so I have not tested either of these examples (although the 2.4 example does look pretty much the same as 2.2, IIRC), so just mod my post all to hell if...
Read, L
CONFIG_PNPBIOSO UNT
CONFIG_DEVFS_FS
CONFIG_DEVFS_M
CONFIG_DEVPTS_FS
CONFIG_PCI_GOANY
which shrank the bzImage to 1381222 bytes -- just within the 1474560 bytes of a 1440kB-formatted floppy. One minor holdup: at first I couldn't get a bootable system because PnPBIOS kept crashing, so I removed it and then the system booted ok. Apparently several of the components on this very new Via motherboard are not yet supported in PnPBIOS in the 2.6.2 kernel.
Scroogle