HAL 0.1 release
David Zeuthen
david at fubar.dk
Sat Oct 4 11:26:55 EEST 2003
On Fri, 2003-10-03 at 02:46, Eric Gillespie wrote:
> David Zeuthen <david at fubar.dk> writes:
>
> > Anyone else got a take on python vs. XML?
>
> When you first announced HAL earlier last month, you mentioned
> using Progeny's Discover (http://hackers.progeny.com/discover/).
Yes, I was referring to the XML data format of Progeny's Discover.
> I was one of the primary authors of Discover 2.0 and am again
> working on it under contract from Progeny. They had been
> discussing means to get more community involvement and adoption
> for Discover, and i brought up HAL.
Cool.
> So, what might you want out of Discover and how can we help?
First of all, let me say that I'm very happy to have this conversation.
(in the following, I apologize if I'm stating something obvious or
repeating what is already in the hal spec, but I feel it is important to
be precise when discussing this)
Let me start be stating the HAL architecture in more detail than given
in the spec (I'll make a proper diagram for hal spec 0.2-wip one of
these days)
/------------------\
| physical devices |
\------------------/
|
| (Bus; e.g. usb, pci)
|
+-----------+ (notifications) +--------------+
| OS kernel |-------------------+ | support libs |
+-----------+ | |(eg. libghoto)|
| V | that links |
+------+ (dbus msgs) +----------------------+ | with libhal |
| (reads +---------| hotplug subsystem | +--------------+
| from) | | (e.g. linux-hotplug) | ^ (gives a
| | +----------------------+ | HAL device
| (links with) | V unique ID)
| |libpci|--+ | (communicates with +---------------------+
+>|libusb| | V hald through libhal +---->| applications (many) |
|libps2| +------+ using dbus) | +---------------------+
... | hald |<----------------------+ ^
+------+ V | (instance of)
| +-------------------+
| (links with) | gnome_hal_watcher | # gnome is
| +-------------------+ # just an
+------------------+ | # example
| libhaldeviceinfo |-----------------+
+------------------+ (links with)
^
| (reads from)
|
/-------------------\
| device info file |
| databases |
| (remote or local) |
\-------------------/
I hope the diagram makes sense. In HAL 0.1 only hot-plugging of USB
devices is supported, but the idea is to probe devices when the daemon,
hald, is invoked; hence the use of existing (cross OS) libraries like
libpci, libusb and so on..
It's important to note that *any* device that is detected will have a
device object representing it. A device object got key/value-pairs and
an unique id. The unique ID doesn't mean anything, but it is guaranteed
to be unique across device insertions (as far as possible). The set of
key/value-pairs must satisfy the HAL spec.
Dependent on bus type, certain well known properties are merged into the
device object. So the point of libhaldeviceinfo is really to merge more
information into a device object dependent on bus-specific information.
The information to merge is expressed in .fdi files. For instance,
this[1]
# -*- Python -*-
#
#
import hal
def device_match_keyboard():
p["Vendor"] = "IBM Corp."
p["Product"] = "Preferred USB Keyboard"
p["Category"] = "Input"
p["DeviceInfoFileVendor"] = "Free Desktop Project"
p["DeviceInfoFileId"] = "org.freedesktop.Hal.IBMPreferredUSBKeyboard.Keyboard"
hal.set_properties(p)
hal.match()
def device_match_hub():
p["Vendor"] = "IBM Corp."
p["Product"] = "Preferred USB Keyboard"
p["Category"] = "Hub"
p["DeviceInfoFileVendor"] = "Free Desktop Project"
p["DeviceInfoFileId"] = "org.freedesktop.Hal.IBMPreferredUSBKeyboard.Hub"
hal.set_properties(p)
hal.match()
p = hal.get_properties()
if p["Bus"]=="usb" and p["usb.idVendor"]=="4b3" and \
p["usb.idProduct"]=="3005":
device_match_keyboard()
if p["Bus"]=="usb" and p["usb.idVendor"]=="4b3" and \
p["usb.idProduct"]=="3006":
device_match_hub()
is a .fdi file (in python, the old format to be replaced by XML) that
matches my IBM USB Preferred Keyboard. Note that .fdi files must be able
to set properties dependent on the OS, XFree86 version and so on.
Note that the prime user of libhaldeviceinfo is hald (for merging when
discovering a device), but it could also be a desktop environment
hardware manager (what I call e.g. gnome_hal_watcher) may want to
traverse the database of available device info files - this is useful
when having multiple .fdi files to select or when creating new .fdi
files based on the users input (the "What did you just plug in?" part
from Havoc's paper). So, that's why it's abstracted into a library.
In HAL 0.1, libhaldeviceinfo embeds the python interpreter and traverses
a set of directories containing .fdi files. The information made
available for determining when a device matches a .fdi file, is embedded
in the existing bus properties in the device object (e.g. usb.idVendor
etc).
Enough about HAL...
My understanding that the Discover Library basically does two things
(please correct me if I'm wrong here)
o Probe all busses e.g. usb, pci
o Merge properties from XML files
On probing devices, i'd like to retain this in HAL for architectural
reasons; probing busses (or handling hotplug events) and matching device
info files are separate things..
I think the Discover XML data format can be made to work with HAL
without many changes. For instance this Discover file
<device busclass="0300" vendor="1002" model="4654"
model_name="Mach64 VT [264VT FT]">
<data class="xfree86">
<data class="server" version="[4, inf)">
<data class="name">XFree86</data>
<data class="device">
<data class="driver">ati</data>
</data>
</data>
<data class="server" version="(0, 4)">
<data class="name">XF86_Mach64</data>
</data>
</data>
</device>
could, in the context of the HAL spec, look like
(note: the HAL spec doesn't define the pci.* or XFree86.* yet)
<device Bus="pci" pci.vendorId="1002" pci.deviceId="4654">
<data class="Category">Video</data>
<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>
<data class="XFree86">
<data class="server" version="[4, inf)">
<data class="name">XFree86</data>
<data class="device">
<data class="driver">ati</data>
</data>
</data>
<data class="server" version="(0, 4)">
<data class="name">XF86_Mach64</data>
</data>
</data>
</device>
(I'm not sure the first line is valid XML, but the idea is to
match on existing properties in the object)
So, I guess that one way to use existing code from the Discover
library is to put it in libhaldeviceinfo or make libhaldeviceinfo link
with libdiscover.
The interface to the discover code could accept two objects - one for
the device that needs to matched, e.g.
Bus=pci
State=needs_device_info
Parent=<hal device id of parent device>
pci.slotName=00:07.2
pci.vendorId=1002
pci.deviceId=4654
..
(this is derived from bus-probing or hotplug handling in hald)
and one with operating system information e.g.
OS=Debian GNU/Linux
OS.version=3.0
OS.kernel=Linux
OS.kernel.version=2.4.22
XFree86.version=4.3
..
(this is derived from a hald configuration file or probing)
and on a match we get the *additional* properties in the device
object
Category=Video
Vendor=ATI
Product=Mach64 VT [264VT FT]
pci.vendorName=ATI
pci.deviceName=Mach64 VT [264VT FT]
XFree86.name=XFree86
XFree86.device.driver=ati
DeviceInfoFileVendor=SomeVendor
DeviceInfoFileId=SomeUniqueId
Now, XFree86 might pick this information up (note that the PCI.slotName
property still exist) using libhal instead of having the user to edit
XF86Config.
I'm not pretending this is the only or best solution in using discover,
so I'm very happy to continue discussing this.
Many thanks,
David
[1] :
http://x2.freedesktop.org/cgi-bin/cvsweb/hal/hal/device_info_files/10freedesktop/ibm_preferred_usb_keyboard.fdi?rev=1.1&content-type=text/x-cvsweb-markup
More information about the xdg
mailing list