HAL 0.1 release

[David Zeuthen]

On Thu, 2003-10-09 at 22:27, Eric Gillespie wrote:
> 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.

Ok, I'll try ;-)

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

Well, we can let the busses share attribute names, it just doesn't feel
that nice. 

For the record, here are some of the attributes I catch for PCI devices
(using libpci) and USB devices (currently parsing
/proc/bus/usb/devices); the probed values are usb.* and pci.*. 

(note that all the number values are in decimal as the types are
integers and not strings)

 device_id = 'pci.00:08.0'
  Bus=pci
  pci.busNumber=0
  pci.slot=8
  pci.function=0
  pci.vendorId=4701
  pci.deviceId=6520
  pci.vendorName=ESS Technology
  pci.deviceName=ES1978 Maestro 2E
  pci.subsysVendorId=4136
  pci.subsysVendorName=Dell Computer Corporation
  pci.subsysDeviceId=158
  pci.subsysDeviceName=009e
  pci.revision=16
  pci.class=4
  pci.subClass=1
  pci.programmingInterface=0
  pci.className=Multimedia audio controller

 device_id = 'usb.1203.12293.1.000000'
  Bus=usb
  usb.linux_devfs=/proc/bus/usb
  usb.linux_device=/proc/bus/usb/001/005
  usb.idVendor=1203
  usb.idProduct=12293
  usb.revisionProduct=1.0
  usb.bDeviceClass=0
  usb.bDeviceSubClass=0
  usb.bDeviceProtocol=0
  usb.busNumber=1
  usb.deviceNumber=5
  usb.levelNumber=2
  usb.parentNumber=4
  usb.portNumber=0
  usb.busCount=1
  usb.speed=12
  usb.version=1.1
  usb.VendorString=Silitek
  usb.ProductString=IBM USB HUB KEYBOARD
  Parent=usb.1203.12294.1.000000
  GotDeviceInfo=false
  State=need_device_info

(apologies for the long listing; note that I still need to find out how
to deal with multiple USB interface.. looking for my USB speakers)

It just doesn't seem practical to me to merge this stuff into a single
namespace even though there is a significant overlap. I'm mean there are
things in USB that is not in PCI, and vice versa.

In either case, it's not terribly important to me.

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

Assuming you can get a Vendor ID - I'm thinking legacy busses like PS2
and serial cannot provide this?

My point is really that if you introduce a new bus, and that doesn't
really that often, you're bound to introduce new attributes.

Assuming you want give all these attributes to match on and/or give all
these attributes to applications/libraries using libhal. I think we
should indeed give all this information. vendor/class isn't sufficient. 

I'm specifically thinking that e.g. Dell might want to match on
subsystemVendorid to provide their own drivers as an OEM.

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

Yes.

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

Agreed. I'm just for having a property for each of them - it's easier on
the application programmer.. no big deal...

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

Yeah.. but.. Joe and Seth raised some interesting points in other parts
of the thread. That your MP3 player is both an "Audio Player" and
"Storage Device"; the "what can it do?" vs. "what is it?". Capability
might be a better word.

It's really about giving hints to the desktop environment on how to
treat the device. This is obviously something we cannot infer from the
hardware bits, so we might require such data to be merged.

Hmm...

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

I don't know about that - I use libpci for doing it but my understanding
is that libpci actually uses pci.ids internally. But it's a moot point
since we agree this comes from the XML files by matching on vendor,
model.

So currently in discover the vendor has to provide two XML files, the
*-device.xml and *-vendor.xml. 

I think it might be more practical that the vendor ships only one file
even at the cost of having to merge the property names for each device.

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

Agreed, certainly; I was thinking of the home user editing these files
himself.

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

Agreed.

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

Well yeah, this is what I tried to say, but it wasn't really that clear
I admit.
 
In fact applications like Nautilus can store data associated with a
device, e.g. the windows position (Havoc's example). Some properties may
also be per-user.

But the important data need to be well-specified, cf. your spec with
XFree86.

Cheers,
David