best way to determine devices with drivers

Ikke nicolas.trangez at
Wed Jun 23 23:51:05 PDT 2004

> This sounds exactly what the .fdi system should be like. The only
> problem is how this is managed - do you include tags in the .fdi file
> for which driver the device uses for Linux/BSD/Solaris etc? This could
> get complicated if you are relying on people manually creating .fdi
> files, but then again I assumed the concept was that software would
> build .fdi files as opposed to people - a device is plugged in, HAL
> checks the local store of .fdi files then the network store for a
> corrosponding file, if the file is not found the system builds as much
> of the file as possible and then asks the user a few simple questions
> with drop down combo boxes to fill in the blanks in the file. This means
> that only a single person needs to fill in the details for each device.
Can't this be done with that other project one mailed here? Can't
remember the name. David, we had a little chat on this, remember?

> This is the assumption that I made from Andy's original post, and I
> think this is a *very* important project. The weakest part of the whole
> project utopia system is the driver reliance - the whole system falls
> down if the driver is not present, or the user does not know how to
> install a driver. It would be great if the system could see that I have
> plugged in XYZ device, then it sees that I have kernel 2.x.x and
> downloads the relevant driver for my distribution.
Can a driver compiled against, let's say, 2.6.0-vanilla, work with my
2.6.7-love1 kernel? Or can a Redhat user use the same modules as a
Suse user?

> The challenge with this system seems to be how well you manage driver
> installation and distribution. It seems that so long as a driver can be
> compiled as a module, it should theoretically work with the right kernel
> version, but how do you ensure that dependent kernel options are turned
> on. As an example, USB mass storage is useless if USB support is not
> turned on.
Some grep magic and a long long list of dependecies?

> Also, do you keep the kernel modules in a centralised network
> source and download a binary, or is the module compiled automatically?
> Compilation could be tricky as the user may not have the kernel source
> available, therefore binary modules would be the best option.
I think compiling if the sources are aviable is the best thing to do
(see first comment).
This is a nice project indeed, but I'm afraid it's more difficult than
one expects now. But keep going! If this gets done, it'd be great for
the Linux desktop.

Regards, Nicolas

Ivman dev -
Blogging @

hal mailing list
hal at

More information about the Hal mailing list