best way to determine devices with drivers
Ikke
nicolas.trangez at gmail.com
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 - http://ivman.sourceforge.net
Blogging @ http://blog.eikke.com
_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal
More information about the Hal
mailing list