best way to determine devices with drivers

[David Zeuthen]

On Wed, Jun 23, 2004 at 11:46:05PM +0000, Jono Bacon wrote:
> David Zeuthen wrote:
> 
> >This sounds a bit backwards to me; wouldn't it be smarter to record what
> >kernel module or userspace library is needed per device rather than
> >tracking what devices/libraries applications use? The .fdi files in HAL
> >might help with this.
>
> 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? 

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 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.
> 

Right. 

> This could work well with details of drivers as people on Linux can
> specify the right driver for Linux, and people on other systems can do
> likewise.
> 

Yeah.

> >Let's see if I understand correctly; For example, if I insert a
> >removable harddisk and there is a NTFS partition, your software will
> >download the NTFS kernel module, install it and insmod it? If so, how do
> >you plan to tell the desktop this (I assume it will take some time to
> >download etc.)? D-BUS? 
> 
> 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.
> 

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. 

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. 

And you really need the ask to user if they trust the software or want
to download it at all, which means you need a channel from the system
to the session - D-BUS seems like the perfect good choice here. And you
need lockdown features for those enterprise desktops etc.

> 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. 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'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 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 :-)

> This seems like an inherently great idea that is really viable. I really
> hope you stick with project Andy and have something up and running soon
> - I really cannot stress how important I think this is.
> 

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.

Cheers,
David

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