Linux users want two things for their hardware: drivers; and easy access to those drivers. The first is finally happening; and now, thanks to a Dell Linux project called DKMS (Dynamic Kernel Module Support), the other is on its way. Dell and Linux distributors have been working on DKMS for about five years now. Its purpose is to create a framework where kernel-dependent module source can reside, so that it is very easy to rebuild modules. In turn, this enables Linux distributors and driver developers to create driver drops without having to wait for new kernel releases. For users, all this makes it easier to get up-to-the-minute drivers without hand compiling device drivers.
I am just amazed how good times are for Linux right now.
This help from Dell is more than welcome and along with announcements from HP and AMD/ATI I can’t help having a big smile all day long.
I think that the actual work and partnership is more important than the actual product/technology. Not saying that DKMS isn’t great, cause it is.
This is great news indeed.
One less thing users need to concern them about is a good thing in my book.
I wonder why Dell didn’t use this thing instead of issuing new Ubuntu cds?
Edited 2007-09-23 15:57
They probably didn’t have the dpkg related bits back then or they weren’t tested enough yet.
I wish I was smarter, but I just don’t get it. I’ve never heard the term driver drop before, but I take from context that it means somehow being able to make it possible to use drivers run on kernel versions that they weren’t designed for? Help me out here, please. 😉
DKMS is a framework that enables a vendor to quickly implement new drivers without the need to recompile the whole kernel. Thus more userfriendly and for the vendor ( in this case Dell) a more efficient way of giving service and support.
I don’t see why you can’t do that (“implement new drivers without the need to recompile the whole kernel”) with the current kernel development model. Oh, well, I do see some reasons, if you’re a corporation going only after money.
See, what happens is that hardware vendors would like to be able to circumvent the kernel development team. They’re waking up to the smell of Linux starting to make sense as a consumer platform, but they don’t like the open source and free software any more than they ever did. They’d love a method of being able to put their binary blobs in there.
Normally, you’d give the code to the Linux source base, perhaps sponsor a dev to maintain it or have your own guy do it. Maximum compatibility and quality. The benefits of open source.
But we can’t have that, can we? Us corporations gotta have our corporate secrets and binary blobs. So here’s the modus operandi:
1. Target a couple of “commercial” distro’s.
2. Cut the Linux devs out of the loop.
3. Profit.
They can’t possibly match the vanilla stuff for quality and compatibility with every new release. So in turn they’ll just release for specific distro’s and that’s all, folks. As a bonus, we’re going to see the kind of driver madness and screw-ups we see on Windows, driver and vendor lock-in, sacrificing quality for backward compatibility and all those nice things that the Windows platform has accustomed us to.
The question now is, which Linux distro’s will whore out for money. SuSE is a no-brainer. I’m curious about Ubuntu.
Edited 2007-09-23 22:32
Some of you dont seem to get it. This package has a lot of uses besides the proprietary uses. DKMS allows for on the fly drivers to be loaded into the kernel on boot. Normally every time you update to a new kernel, you have to go through and manually compile all the extra crap you installed to work with it. Vmware, Nvidia drivers, user space drivers. With DKMS, you get a new DKMS package with the new kernel and you are good to go. Well, except with vmware which isnt using this system yet, (but they did open source their tools, so maybe soon).
As for companies not liking linux, thats BS. MOST companies that create hardware are writing the drivers on either linux or BSD. Why? Because you can delve right down into the kernel to see whats going on. You cant do that with Windows. This is one reason why Linux actually has pretty decent hardware support.
Oh, lay off the big words. “Most” companies? You jest. What happened with the myriad of software drivers that are only available for Windows and make their corresponding piece of hardware a brick on Linux? Why do we have to keep reverse engineering and guessing so much stuff?
So who’s fault is that? Why don’t they put their code in the main kernel? So when I get my new kernel their stuff is already in there. Problem solved.
Let’s face it, this whole DKMS thing is not a solution to any real technical problem, it’s just a way to circumvent the main issue: companies, put out your driver code or piss off.
My preferred way to get drivers on Linux is via the Linux kernel. I sleep better at night knowing it’s been reviewed by the Linux devs, that’s nothing evil in it, that it work well with the rest of the kernel, that it’s going to be maintained for as long as there’s a maintainer. Not to mention the added benefits of free software, as bestowed upon me by GPL.
If companies don’t like this way of doing things, tough luck. I won’t buy their hardware if it doesn’t work on Linux, obviously. They can do what NVidia is doing and if the driver they put out that way is working well with ANY kernel I use and if I can be bothered to jump through some hoops to get it installed, I’ll do it. Depends on how great their hardware is, my current mood and so on.
But do NOT try to institutionalize this way of doing things and pass it off as a good thing for Linux users. There’s one way of doing drivers right on Linux and this is not it.
The bottom line is that I think you’ve completely misunderstood the idea behind this. Yes they do want to circumvent the whole Linus approved process but more importantly a framework would allow for an easier and faster development and could eventually attract a lot more companies to linux support. Right now it is quite expensive for a company to create a linux driver for it’s hardware because linux driver developers are not that easy to come by and they are also quite expensive compared to windows ones. Considering the small market share of linux it is no-brainer than Dell would be pushing for some changes. Oh and Novell has absolutely nothing to do with this initiative. I don’t know why you’d think otherwise … they sell software not hardware.
One advice: pay attention. Your post is completely messed up.
I was talking of SuSE as an example of a distro that would readily embrace the DKMS way of doing drivers, not as a hardware vendor.
And you seem to be under the impression that DKMS means companies don’t have to write code anymore, somehow. Please share what you’re smoking.
Sounds quite similar to Debian’s module-assistant, but more distribution independent.
I really like the idea of something in-between vendor provided driver installers and drivers included in the kernel.
Already managed by the system’s package manager but still available across a wide range kernels.
Been using dmks modules (binary nvidia and ipw3945) since fedora 7 came out (with the freshrpms.net repository).
This makes it really easy to install modules for a new kernel, since you don’t have to manually recompile/reinstall them for the new kernel. Thats done automatically the next time you reboot.
This makes it really easy to install modules for a new kernel, since you don’t have to manually recompile/reinstall them for the new kernel. Thats done automatically the next time you reboot.
Updated drivers have been found for your hardware. Reboot?
[ Now ] [ Yes ] [ OK ]
I can’t wait.
IIRC, this was just a WDM-like thing, and it has been rejected in the past. yes, its authors announced it in the linux kernel.
AFAIK the idea of that “upgrading drivers” mechanism was to have an stable driver abi.
edit. no, as said here http://osnews.com/permalink.php?news_id=18667&comment_id=273632 it’s just a sort of automatic compilation mechanism
Edited 2007-09-23 16:55
Many moons ago Caldera worked on a single UNIX driver kit specification; too bad it never got any further than just an idea on paper.
No. The idea is to build the modules centrally or make the building an invisible step of installing.
The driver authors still “drop” the drivers’ code, but the users can install it as a distribution package without having to upgrade the kernel image package.
Er…on its way?
We’ve been using DKMS to handle various modules in Mandriva (most notably, ATI and NVIDIA commercial drivers) for several years now. I think at least four years. Current list of dkms handled modules in Mandriva:
dkms-abituguru
dkms-actuator
dkms-adm8211
dkms-alsa_raoppcm
dkms-cdemu
dkms-cluster
dkms-dvb-ttpci-sc_patched
dkms-em8300
dkms-et131x
dkms-fcdsl
dkms-fcdsl2
dkms-fcdslsl
dkms-fcdslslusb
dkms-fcdslusb
dkms-fcdslusb2
dkms-fcdslusba
dkms-fcpci
dkms-fcusb
dkms-fcusb2
dkms-fglrx
dkms-fglrx-hd2000
dkms-fuse
dkms-fusion
dkms-fxusb
dkms-fxusb_CZ
dkms-gspcav1
dkms-hcfpcimodem
dkms-hsfmodem
dkms-ipw3945
dkms-iscsitarget
dkms-ivtv-0.10
dkms-ivtv-0.7
dkms-kqemu
dkms-lazyfs
dkms-libafs
dkms-lirc
dkms-lirc-gpio
dkms-lirc-parallel
dkms-madwifi
dkms-mcs7830
dkms-minimal
dkms-ndiswrapper
dkms-nvidia-current
dkms-nvidia71xx
dkms-nvidia96xx
dkms-omfs
dkms-omnibook
dkms-opencbm
dkms-ozscr
dkms-pcc-acpi
dkms-pwc
dkms-qc-usb-messenger
dkms-realcrypt
dkms-slmodem
dkms-syntek
dkms-unicorn
dkms-unionfs
dkms-usbvision
dkms-virtualbox
dkms-visdn
dkms-vloopback
dkms-zaptel
dkms-zd1211
I was about to say the same thing ..
Mandriva has been using dkms since it was Mandrake .. but interestingly enough, the article mentions about every distro, except mandriva … which then again, was one of the first distros to trust, implement, work on, and use dkms as a mean to distribute kernel modules.
The title is misleading, why “coming soon”? Mandriva used to innovate in the past and to look forward: DKMS has been shipping with Corporate Server 3.0, and in any consumer distro since Mandriva Linux 10.1 (3 years now).
At some point, there were also discussions with key vendors like ATI and nVidia (and others) to provide DKMS packages directly upstream, which is the case for ATI thanks to a great and patient kernel developer: rtp (what does it mean? ;-)).
interfaces change now?
I thought most Linux fanboys used to defend Linux by saing that it doesn’t matter if Linux changes kernel API frequently because all the drivers are recompiled with the kernel.
What happens with drop-in drivers?
And btw this facility has been available on other OSes for ages.
“interfaces change now? ”
Hint: read the article instead of just posting without understanding.
That should make for a couple of nice flamewars about non-GPL modules linking to the kernel – not like I care though.
If DKMS means automatic compilation, no flamewar should ensue, since it’s source not binaries that is distributed.
The key word here being “if”.
I’m having a bit of trouble believing vendors will suddenly flock to deliver via DKMS if it involves source code. They could have put code in the vanilla kernel at any time, why now?
They didn’t because they don’t like to open source their drivers and because they don’t like the idea of GPL aka free software. I don’t see what’s changed.
At most, we’ll see stuff like NVidia’s thin layer of code over a big binary blob.
While I’d enjoy more Linux drivers as much as the next Linux user, I have to question the methods and motives I’ll get them for.
Of the DKMS handled drivers in Mandriva listed in my post above, you will note that the vast majority are open source. Out-of-tree kernel modules, open source and otherwise, have always existed. DKMS is simply a system which makes it rather easier to handle them.
Than if it involves open source and is already used, this is not news at all. Dell is making use of something the distro’s were already offering. As they should.
Dell wrote DKMS.
Just while reading your post I had an idea.
What if you made a GPL module linking to the kernel and make a non-GPL module linking to your own GPL-modul?
It would still be a GPL violation but only the copyright holder is allowed to take legal action oo oppose that.
And as you are the copyright holder you hardly will sue yourself.
Wouldn’t that be a way to ignore the GPL on the kernel?
If that is possible with GPL v.2 are there plans to make it impossible in the futur?
No one seemed to mention SUSE. SLES was certainly using dkms at very least 2 years ago when I was managing SLES9 servers at work. We had to use it for the nvidia proprietary network drivers in some Sun servers. Those nics still suck.
SUSE is mentionned in the article.
thankfully seems to become popular finally
… it’s pretty easy to install drivers: you just need the kernel headers and the standard toolchain. How is this DKMS stuff any easier to work with than getting out-of-tree module stuff in a tarball and doing the old make;make install routine? Are people really so pressed for space that they can’t keep the kernel headers and source on their HD to compile new drivers?
it automates the process and runs it at boot time, so that it’s essentially transparent to the user. “getting out-of-tree module stuff in a tarball and doing the old make;make install routine” may meet your definition of user-friendliness, but not many other people’s.
in the end its a daemon or similar thats fired up at boot, checks the kernel version, and if that have changed, initiates a recompile of the modules under its care.
but one question, how long will that take? must the user wait for the compiles to complete before the computer can be used?
or maybe it can be triggered as part of the installation of the new kernel, before any reboot is taking place?
Browser: Mozilla/5.0 (X11; U; Linux armv5tejl; no-NO; rv:1.9a6pre) Gecko/20070810 Firefox/3.0a1 Maemo browser 0.4.34 N770/SU-18
in the end its a daemon or similar thats fired up at boot, checks the kernel version, and if that have changed, initiates a recompile of the modules under its care.
but one question, how long will that take? must the user wait for the compiles to complete before the computer can be used?
or maybe it can be triggered as part of the installation of the new kernel, before any reboot is taking place?
Browser: Mozilla/5.0 (X11; U; Linux armv5tejl; no-NO; rv:1.9a6pre) Gecko/20070810 Firefox/3.0a1 Maemo browser 0.4.34 N770/SU-18
As someone already said, this is functionally equivalent to Debian’s module-assistant.
Since someone listed kernel modules handled with DKMS in Mandriva, here’s the list of kernel modules handled with module-assistant in Debian, for comparison.
As you can see, it’s more about out-of-tree modules, not about binary modules.
acx100-source
affix-source
alsa-source
arla-modules-source
at76c503a-source
bcm4400-source
bcm5700-source
cdfs-src
cipe-source
cloop-src
comedi-source
cpad-kernel-source
cryptoapi-core-source
cryptoloop-source
dazuko-source
ddrmat-source
device3dfx-source
drbd0.7-module-source
drbd8-module-source
dvb-driver-source
e100-source
eagle-usb-modules-source
em8300-source
exmap-modules-source
fglrx-kernel-src
freeswan-modules-source
ftape-source
ftpfs-src
fuse-source
fwatch-modules-src
gpib-modules-source
hostap-source
hubcot-source
i2c-source
ieee80211-source
ipw2100-source
ipw2200-source
ivtv-source
kqemu-source
linux-uvc-source
linux-wlan-ng-source
lirc-modules-source
lm-sensors-source
loop-aes-ciphers-source
loop-aes-source
lufs-source
madwifi-source
mga-vid-source
misdn-kernel-source
ndiswrapper-source
nozomi-source
nvidia-kernel-legacy-source
nvidia-kernel-source
openafs-modules-source
openswan-modules-source
ov511-source
pcmcia-source
plex86-kernel-src
ppscsi-source
qc-usb-source
qla2x00-source
realtime-lsm-source
rt2400-source
rt2500-source
rt2570-source
rtai-source
shfs-source
sl-modem-source
spca5xx-source
squashfs-source
sysprof-module-source
thinkpad-source
tidev-modules-source
translucency-source
tun-source
unicorn-source
unionfs-source
userlink-source
vaiostat-source
video4linux-nw802-source
wacom-kernel-source
xdslusb-source
xlibmesa-drm-src
zaptel-source
zd1211-source
That Greg KH was foisting on the community and scaring away potential 3rd party driver developers
folks – this project from dell is essentially a way to make precompiled drivers work on any kernel and to prove that module versioning was utter BS from the kernel developers
Edited 2007-09-24 03:36
No. It’s not. Not at all. It is an automated way to recompile drivers against a given kernel. It does not magically make a driver that was compiled against kernel X work with kernel Y without recompilation.
I read the article, thought hmmm, what a great idea!, then I read here that the ulterior motive might be to flout the kernel devs, and insert WINDOWS QUALITY drivers into my system. That would be tremendously foul. If there was one thing indelibly imprinted on my soul from my years in MS $lavery, it was that all the horrible problems with my (and your) systems were the fault of third party drivers, and not Its Holyness the NT kernel. Bringing this to Linux on any large scale would be a tragedy of Shakespearian proportions.
I did see a reference in the article to linking to and compiling source. I figure, if it is source based, and can be thus vetted, it would be nice to unlink driver versions from kernel versions (as long as they are compatible).
Apparently DKMS is of absolutely no use to people who compile their own kernels, or for any source based distros like f.ex. Gentoo. And that sucks
I know GPL purists will hate me after saying this, but I would really love a STABLE API for drivers and the possibility of downloading PRECOMPILED binaries, GPL or NOT, from the net when needed…That’s something that would benefit a whole lot of people and make using linux just a great deal easier! Of course, it would be best if the system preferred GPL ones and would inform the user if it would install non-GPL ones. But well, I don’t think that will ever happen. GPL purists make sure of that.
If this is the only way to get more companies to support Linux for these devices, then so be it.
I would just *never* trust this “out-of-tree” 3rd party driving building crap for use on my servers.
Also, companies that dont work with the kernel devs to get their drivers into the mainline at some point are going to have a tough time keeping up. These are the same people who wanted an ABI for the kernel, but having such a petrified casing over the evolution of this software wouldve defeated a major point of having an open source kernel in the first place, since one of its main purposes is to run your devices, after all
Edited 2007-09-25 14:18
That is the beauty of this solution … if you want it, use it … if not, don’t.
The only problem I have with it at this point is that it requires a rebuild on your server, meaning that you need to have all the things required to build it on each machine.