Print

Direct2Dell

Sign in
Sign in to post messages.
Joined on 09/21/2006 Posts: 119
Points: 12460
Bronze

DKMS and biosdevname releases

This week I've managed to clean up my TODO list quite a bit, including getting releases of two apps I maintain out the door.

First, I've posted DKMS v2.0.17.4.  Big changes include a couple fixes:

  • installs during --rpm_safe_upgrade could incorrectly fail
  • SLES10 driver disk creation was broken (and may still be)

and a few features:

  • Ubuntu packaging and mkdeb command (this has been accepted into Ubuntu Universe for Gutsy)
  • mkrpm now add automatic Provides: lines with modalias info.  This will eventually be used to automatically download drivers that match the hardware you have in your system but which aren't presently in your $distro's kernel.  Thanks to Michael Brown for his hard work on this feature.
Dell uses DKMS to distribute updated device drivers for RHEL, SLES, and Ubuntu built against the "gold" kernels of those products.  This lets us fix and replace individual device drivers to support new hardware without having to respin the whole CD (like we wound up doing for Ubuntu).

Downloads: http://linux.dell.com/dkms/permalink/
Git repo: http://linux.dell.com/git/dkms.git/
and from some of your favorite distro repositories:  Ubuntu Universe for Gutsy,  Fedora rawhide and Fedora 7 testing.

Second, I've been working with Harald Hoyer and Kay Sievers to integrate biosdevname with udev rules cleanly.  Version 0.2.4, along with the
latest udev, accomplishes that.  Biosdevname addresses the challenge of properly assigning names to network devices inside of Linux to be consistent with the names the BIOS would give, and that match the labels on the chassis.

In addition, I'd like to thank the folks who contributed in this release.  Bernhard Walle provided a segfault fix, and Kay helped me
track down another segfault in the pcmcia code path.  Rudy Gevaert contributed the Debian packaging, Michael Brown performed some
makefile magic, Harald provided an RPM specfile patch, and Matthias Saou reviewed the package for Fedora.

Downloads: http://linux.dell.com/files/biosdevname
Git repo:      http://linux.dell.com/git/biosdevname.git
Distributions: built for Fedora rawhide; if building for Debian or Ubuntu you'll want the latest code from git.

You must Login to comment.
  |  Del.icio.us   |  Digg   |  Reddit   | 

 

@Charles: yes, I would like to see biosdevname included in Ubuntu, just as it's included in Fedora today and will be back in openSUSE now that 10.3 is released and they can upgrade to a new version of udev.

 I took the time to package DKMS for Ubuntu and the MOTU team was very helpful in getting that included.  biosdevname is in pretty good shape, but I don't have the time to really maintain all these apps (firmware-tools, biosdevname, ...) as both upstream and in each distribution.  I'd welcome help from Debian Developers and/or Ubuntu members (MOTUs or those who want to become a MOTU) in maintaining these apps in the distributions.  libsmbios has a good Debian maintainer from the community - I'd love to see the same model for some of our other apps.
 

 
Are there plans for the work on biosdevname to be added to the Ubuntu repositories in the near future? Thanks!
 
Glad to see Dell does great job which will allow users to
have choice. Here in Russia lots of people tired from buying
licensed OS which will be ... deleted anyway.And it is awfully hard to get refund for unused OS copy.That's annoying and actually seems ti be against local consumer protection laws. I'm really want to be able to choose hardware I will like and OS I will like separately.So I can use my favorite hardware with my favorite OS.As for me, my OS of choice is Kubuntu up to date.
 

Sorry I'm so late to the party - thanks for the good work!  Any chance of getting updated e1000 and/or snd-hda-intel drivers into the DKMS infrastructure?  I just bought a Vostro 200 and Centos 5/RHEL5 both run but I have no sound and the onboard NIC won't work without updated drivers from Intel.  Maybe I'm just looking in the wrong place...

 

Thanks 

 

Hi Matt,

first of all - great work - thank you!. Second, will Dell actually help make ATI drivers that really work under Linux? I have stayed far away from any ATI technology due to the fact that NVIDIA drivers have fared so much better for years now.

Sincerely,

Chuck

 

 
7wolf: these applications are mostly hardware-independent - they'll work on any system, by any hardware manufacturer.  DKMS itself is just infrastructure code, to be used by other packages that provide new device drivers.
 

Can this version work with Dell Vostro 1500/Inspiron 1520?

Thanks a lot 

Sorry for my poooor english 

 

Thanks for the great work with ubuntu so far.  I'm really happy with it on an E1505.

I am testing gutsy on a separate partition.  I note that the hsfmodem driver will not work on gutsy, but still works fine on my other feisty partition.  Probably an update is needed for the gutsy kernel.

Would dkms be useful in building the hsfmodem module, or is it just for open source modules?

 

 

 

hsfmodem does most likely need to be updated to recognize the Gutsy kernels.

hsfmodem provides its own set of scripts that perform much of the same functions as DKMS.  It aims to have a single package (deb or rpm) that can determine what kind of system it's on, where the kernel pieces it needs are, and compiles its source code shim + precompiled binary component into a new kernel driver.  DKMS could be used to do the same thing.  However, DKMS expects the source code (and yes, precompiled binary blobs when necessary) to be built using the normal kernel Kbuild environment; the hsfmodem code isn't laid out in that manner, so DKMS can't make use of it in its current form.

One of the goals of DKMS was to replace each of the custom drivers' build scripts like hsfmodem has, and like many other 3rd party kernel modules each have.  That is a duplication of effort that could better be spent working on open source drivers. Lots of modules now use DKMS for their build environment, particularly 3rd party repositories associated with Fedora, the extra packages provided by Mandriva and PCLinuxOS, and of course, everything Dell releases for RHEL, SLES, and even some Ubuntu.  So while it's not world domination yet, it's making good progress. :-)


-Matt

 

I was quite pleased with the collaboration, in particular,
my interactions with the Ubuntu MOTU and kernel teams to get DKMS included in Ubuntu, and the assistance of Harald and Kay on the linux-hotplug-devel mailing list to enhance udev so that biosdevname could integrate into it cleanly (not to mention the actual bugs they reported and provided fixes for).

The only people paid by Dell for any of this was myself (of course) and my colleague Michael Brown.  While Dell has business relationships with several of the employers of the other contributors (Red Hat, Canonical, Novell), these people were primarily acting as the upstream maintainers of their projects, or the distro maintainers, or just interested developers.  They don't turn in a timecard saying "we spent 2 hours working on a Dell problem - go bill them for it." :-)

 

 
Curious George

Matt,

If you are comfortable saying, did those who contribute to this release get paid by Dell or was it entire volunteer efforts on their part?  How well did this collaboration work out?