HAL 0.1 release

[Eric Gillespie]

David Zeuthen <david at fubar.dk> writes:

> If we are going for the goal of being backwards compatible with
> the existing data (which is a nice goal if there are many
> existing files),

Backwards-compatibility is not an issue.  The only widely used
version of discover is the old one based on libdetect.  With
compelling reason, we can change discover's XML format.

> A: We can make this work. First off all, I'd still like to have
> different namespaces for different busses.
> 
> The reason is 1) it's more structured

The current format we use is structured.  What you are suggesting
presents an extensibility problem.  Every time you want to
support a new bus you have to account for new attribute names.  A
vendor ID is a vendor ID regardless of which bus it identifies a
vendor on.

> 2) it will be useful to separate this so we can support
> bindings to libhal for OO languages / libraries, e.g. the Java
> bindings might give a HalDevice object that implements the
> interfaces BusUSB, BusStorage. Same could go for glib.

I don't see how the current format has anything to do with
*bindings*.  You can present whatever kind of API you want; i am
defending the file format.  As long as the data is available in
the file, libhal can present it however it likes.

> means that the XML parsing code looks for "pci.vendor" and
> "pci.model" because it prefixes the bus variable initially
> given. I'm happy to change e.g. pci.deviceId to pci.model to
> accommodate this.

Sounds like you can agree to the above paragraph.

> B: We could do as in A, but it's more visible for the creator
> of the file that he is dealing with a PCI device, so I'd rather
> user pci:deviceId.

That he is dealing with a PCI device is obvious because that
information must be right there in the <device> element he is
creating or modifying.

> > >     <data class="Category">Video</data>
> > 
> > Currently we handle this using the same bus classes used in the
> > PCI IDs (and USB, etc.) files.  I think sticking with that is a
> > good idea.
> > 
> 
> Yeah, 'bus class' is much akin to Category. I found it's been useful to
> think in terms of three different classifications

Yes, except that bus class is an existing system already widely
used, by the hardware itself, no less.

>  Category    = Storage, Network, Video, Camera etc.
> 
>  SubCategory = Magnetic, Optical, Flash, Zip,  # For 'Storage'
>                Ethernet, Modem, ATM, ADSL      # For 'Network'
>                ,                     # For 'Video' (can't think of any)
>                ,                     # For 'Camera' (can't think of any)
> 
>  UserCategory = <same as category>
> 
> So only Category is mandatory. SubCategory, UserCategory is optional.
> The interesting is UserCategory as this is what the UI parts
> will use.

This is how bus classes work, minus UserCategory (i think; i
don't see what it is).

> One example of where UserCategory is of benefit is to consider
> digital camera support on Linux today. So, some cameras appear
> as usb-storage and we want to distinguish them on the UI level
> with an icon.

I think the USB bus classes are that fine grained.

> A: We simply map busclass to the appropriate category / subcategory set

That's what a bus class is.

> > >     <data class="Vendor">ATI</data>
> > >     <data class="Product">Mach64 VT [264VT FT]</data>
> > >     <data class="DeviceInfoFileVendor">SomeVendor</data>
> > >     <data class="DeviceInfoFileId">SomeUniqueId</data>
> > >     <data class="pci">
> > >       <data class="vendorName">ATI</data>
> > >       <data class="deviceName">Mach64 VT [264VT FT]</data>
> > >     </data>
> > 
> > All this is redundant; it is already listed in the attributes of
> > the <device> element.
> > 
> 
> Oh yes, this is normally extracted from pci.ids or usb.ids but
> these files might not be up to date and more importantly, they
> are not from the authoritative source, e.g. the OEM. Also,
> pci.ids and friends are not complete.

We don't extract anything from the ids files.  The main idea
behind discover is that the hardware data no longer has to be
stale.  It can come from any source.  We figured that OEMs would
provide their own XML files, similar to your plan.  So being out
of date isn't an issue.

> Specifying this explicitly, is optional, and it overrides the
> values that are read from the *.ids files.

Hmm, are you saying HAL currently reads from the ids files?  I
guess that's the real source of redundancy.  *All* the data
discover has access to may be (and we expect it to be) overridden
by data from vendors.

> Worst case is that the Vendor is "1002" and the Product is
> "4654", which is bad enough to get fixed since this will appear
> in the UI.

The discover data files include human readable strings
corresponding to all the numbers.

> In general most of fields that is specified with the data tag should
> follow the HAL / Discover specs.
> (HAL specifies something for Storage, while Discover specify the XFree86
> parts)

I don't know what you mean here.  The <data> elements may provide
any payload at all; that was the point.  The Linux module and
XFree86 driver were the only ones we provided as examples because
they were the only two we were actually using.

--  
Eric Gillespie <*> epg at pretzelnet.org