best way to determine devices with drivers

[Jono Bacon]

David Zeuthen wrote:
> One possibility is to do what the Discover suite from Progeny does,
> http://platform.progeny.com/discover/, e.g. have HAL expose global
> properties like
> 
>  kernel.name
>  kernel.version
>  xorg.version
>  ...
> 
> so you have .fdi files looking like this
> 
> <deviceinfo version="0.2">
>   <device>
>     <match key="info.bus" string="usb">
>       <match key="usb.vendor_id" int="0x05dc">
>         <match key="usb.product_id" int="0x0002">
>           <merge key="storage.drive_type" type="string">compact_flash</merge>
> 
>           <if global="kernel.name" string="linux">
>             <if global="kernel.version" range="[0;2.6.42[">
>               <merge key="conf.driver" type="string">usb-storage</merge>
>             </if>
>             <if global="kernel.version" range="[2.6.42;inf[">
>               <merge key="conf.driver" type="string">lexar-usb-storage</merge>
>             </if>
>           </if>
> 
>           <if global="kernel.name" string="freebsd">
>             <if global="kernel.version" range="0;4">
>               <merge key="conf.driver" type="string">some-freebsd-driver</merge>
>             </if>
>             <if global="kernel.version" range="5;inf">
>               <merge key="conf.driver" type="string">a-newer-freebsd-driver</merge>
>             </if>
>           </if>
> 
>         </match>
>       </match>
>     </match>
>   </device>
> </deviceinfo>
> 
> and I'm sure someone can come up with a better XML format :-)

This would solve the issue of identifying kernel versions required for a 
device. I suppose if this is built into the system for automatically 
generating FDI files this will be a none-issue.

> And you want to make this very configurable and integrate with the
> native package manager since I bet that distributions wouldn't like to
> ship software that install software that is not packaged. 

Is packing really that important? If all that is being tranferred is a 
single kernel module I don't really see the need to rely on the package 
manager. So long as the kernel knows about the module, why would the 
package manager need to know?

The other option is to allow the program that gets the module to check 
if there is a module repository for the distribution first and then 
maybe fall back on a generic respository second. Again, I see little 
point in this as the kernel is one of the few approximate unified 
elements of a distribution.

> This implies all sort of fun details like naming convention, e.g. what
> is the name of the RPM or DEB with the NTFS driver. Also, if I'm
> running Fedora I can get the NTFS driver only if I've configured a 3rd
> party non-US repository. 

Exactly. I think if this can be done is a distribution agnostic way and 
as such package agnostic way, this could prevent the issues. There are 
course other issues. Do all kernels store modules in the same directory 
or do some distros pervert this?

> I'm not sure what the answer to all your questions are, but it seems
> to me this is very related to the hardware database proposed just last
> week. 
> 
> But my guess is that you'll need tight integration with distributions
> and OS vendors to make this happen. I'm not sure compiling drivers on
> the fly is the way to go, I think packages sounds like a better idea,
> but I could be wrong.

I think we need to identify the range of the playing field first; how 
many things vary among distributions and kernels. With this in mind a 
better judgement can be made to make this a reality. I think that if a 
packaging route is taken, distribution co-operation will be required. 
Irrespective of whether packaging is used at all, we will still need 
maintainers for different modules.

> I guess it's a lot more complex really - there's the entire free
> software angle to consider like the fact that some people argue that
> kernel modules should all be GPL and in the kernel tree etc. etc. But
> I'm not going to start that thread :-)

I agree, but if this is a limitation, it will kill the project. If 
people are really concerned about getting source and compiling it 
themselves, they will have the knowledge to go and compile the code 
anyway. I would say this project is aimed the less-technical user who 
has no clue about compiling kernels.

> I really agree this is important. It could be interesting to work out
> some of the usecases all the way from the metal through the kernel and
> to the desktop to get an overview what is really needed.

Agreed.

	Jono

-- 
Jono Bacon - http://www.jonobacon.org/
Writer / Journalist / Consultant / Developer

_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal