Plans for hal 0.5.x

David Zeuthen david at
Tue Dec 14 09:51:22 PST 2004

On Tue, 2004-12-14 at 10:46 -0500, Dan Williams wrote:
> Well, since each connection method (USB, serial, bluetooth, etc) is
> actually a hardware device itself, why not show the PDA as a _child_ of
> that device?  We are working with parent/child relationships as a
> fundamental property of HAL already.  

Not really; we actually do use things like block.storage_device,
storage.physical_device instead of relying on parent/child

> Therefore you wouldn't necessarily
> need a "pda.palm.serial_interface" property, you could just ask for the
> "device.interface" (or something) property of the parent of the PDA
> object.  

Nope, it should rather look like this

 pda.access_method = serial
 pda.serial.serial_device = <udi of device with capability serial>

then we can do things like later on defining pda.access_method to be a
kernel driver (not likely, but..) or another kind of interface.
Specifically for, we may have pda.serial.command_protocol to hint what
kind of protocol is used when communicating over a serial port and so

> It would seem like having that property on both the PDA _and_
> the actual device itself would be redundant.  (however, I can see it
> being useful on the PDA so I'm not really objecting to having it there).
> The point is, since we can (and if we can't, then we should fix that in
> HAL) get that information off the parent of the PDA device, is it really
> appropriate to having it on the PDA too?

Look at it from the desktop software point of view. I want it to be
simple and deterministic and not rely on parent/child relationships.
Initially my desktop software may only support pda.access_method==serial
but in the future I might add support for another pda.access_method way
of doing things.


hal mailing list
hal at

More information about the Hal mailing list