hal draft spec

[David Zeuthen]

On Wed, 2003-09-10 at 18:26, George wrote:
> I would try to be as un-dirty with the device-list format as possible.  All
> too often do quick and dirty formats become the de-facto standard :) Although
> I think in this case you don't have to get overly complex with the format as
> long as it's extensible in some way.  It's really just a list of things with
> a bunch of fields right?  (at least so I gather from glancing at your
> proposal.)
> 

Yeah you are right in both regards. On the latter, yes, the device-info
field should just specify what additional fields to add. 

The core of the problem is to match one or more device-info given the
set of information we receive from the hotplug agents and hw libraries.

I'm thinking of initially using a format like this (I hope it is self
explanatory, otherwise just shout)

<deviceinfo>
  <mustmatch key="Bus" type="identity" value="usb"/>
  <oneblockmustmatch>
      <match key="usb.idVendor"  type="identity" value="1fc"/>
      <match key="usb.idProduct" type="hexrange" low="3a" high="4c"/>
    <next/>
      <match key="usb.idVendor"  type="identity" value="2fc"/>
      <match key="usb.idProduct" type="hexrange" low="1a" high="33"/>
  </oneblockmustmatch>

  <set key="Vendor" value="SomeVendor">
  <set key="Vendor[da]" value="TheDanishNameOfTheVendor">
  <set key="Vendor" value="ProductName">
  <set key="Vendor[da]" value="DanishProductName">
  <set key="DriverVendor" value="someone">
  <set key="Category" value="Storage">
  <set key="Persistent" value="true">
  <set key="RequireDisable" value="true">
  <set key="KernelModules" value="usb-storage">
  <set key="BootProgram" value="/path/to/some/os/provided/libhal">
  <set key="ShutdownProgram" value="-linking-program/for/usb-storage">
  <set key="RequireDisable" value="true">
</deviceinfo>

This should be easy to parse. It's probably pretty inefficient too in
terms of storage and driver searching cost due to the quite simple
format yielding many drivers :-) 

Anyway, I still think it is important to have some bells-and-whistles
(Desktop Environment integration) before than having the all-dancing
all-singing device-info format to end them all. 

And it's probably useful to look into the discover format from Progeny -
they have done quite some thinking on device-info files.

One last thing: It would probably be smart to put the handling of
device-info objects into a separate library such that Desktop
Environments can query and modify this list of device-info objects as
the user struggles to configure his device that has no device-info
object (The 'what did you just plug in?' part from Havoc's paper).

For example, the user selects that the device is of the Modem category
and the required properties (cf. my 'draft spec') for this device is
entered by the user (e.g. dial prefix, phonenumber to ISP, login,
password). Other fields, such as KernelModules and BootProgram,
ShutdownProgram is set automatically by the DE agent. The DE agent then
creates a device-info object this way. Sigh.. now we need a format for
device-info object templates :-) ... Comments?

Regards,
David

-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-    David Zeuthen             pgp key:     http://fubar.dk/pgpkey.asc
-  david(at)fubar.dk           pgp key id:                    b89bab82

    "I don't have any solution but I certainly admire the
    problem." - Ashleigh Brilliant