hal spec 0.2-pre

[David Zeuthen]

On Thu, 2003-10-30 at 10:20, Alexander Larsson wrote:
> On Thu, 2003-10-30 at 02:30, David Zeuthen wrote:
> > Hi,
> > 
> > I've compiled most of conclusions from several recent HAL discussion on
> > this list into a new version of the HAL spec. Find it at
> > 
> >   http://freedesktop.org/~hal/spec-0.2-pre/hal-spec.html
> 
> A few comments:
> 
> > * Unique ID (referred to as unique-device-id in the following)
> >
> > This is an identifier that is unique for a device object - that is, no
> > other device object can have this ID at the same time. This ID is
> > computed from bus-specific information so it may (but also may not)
> > even be unique across device insertions and when multiple instances of
> > the same kind of device is plugged in.
> 
> This reads as if its not guaranteed that multiple instances of the same
> kind of device plugged in at the same time get differnt unique ids. I
> hope this is just "typo". We really need to be able to address each
> instance.
> 

Yeah, it's not really clear what I wrote. I'll replace it with this

 This is an identifier that is unique for a device object - that is, no  
 other device object can have this ID at the same time. This ID is
 computed from only bus-specific information so it may be unique across
 device insertions and when multiple instances of the same kind of device
 is plugged in.
 This is important for devices like cameras where desktop applications
 store per-device data, like the name of the camera, in (per-user) properties
 on the device object.

okay?

(per-user properties is not supported yet, but it will be later)

Note that we need to constraint ourselves to computing the device-id
from bus-specific information as this is all we get when a device is
unplugged; hence the "it may" instead of "it is" in line 3.

Rambling on a corner case:

Assume two instances of a camera is to be plugged in. To make it more
nasty, assume that usb.SerialNumber is not available. It is not smart to
use the port/slot information to compute the device-id the user may plug
the camera into another port later and that means our persistent data is
gone.

So that really leaves us with using usb.vendorId, usb.deviceId and
friends to compute the device id. When the second device instance is
plugged in, we arrive at the same device id. But hal_agent.usb can check
this and append a "-2" to the device id so we are home-free with
plugging in the second instance.

When one of the instances is removed, we can make hal_agent.usb do the
right thing by comparing port/slot information. 

Assume now both cameras are removed. What happens when you put in a
camera again? Which persistent camera device-object do you select? There
is no solution for this..

Ok, so this is really a corner case, but it's not a major problem as I
see it.

> > # (TODO: how to implement this in D-BUS properly? What if the process locking
> > #  the object dies? Ping the D-BUS service (e.g. :32-0) holding the lock on
> > #  a regular basis?)
> > #
> > void Lock()
> 
> dbus allows you to detect when a client disconnects from the bus (if
> e.g. the process died). The process could still hang, but this is at
> least some level of protection. You can just kill the hanged process.
> 

Oh, killing processes sounds a bit drastic. I was envisioning that with
the new architecture the HAL daemon would run as a unprivileged user..
Can D-BUS tell if a client is hanging, e.g. by pinging it once in a
while? That would be nice..

> > # Create a new device object which will be hidden from applications
> > # until the Commit() method is called. Returns an object that implements
> > # the org.freedesktop.Hal.Device interface.
> 
> Added(), not Commit() i guess.
> 

Right

> > BootProgram (string)
> 
> How are ';' escaped in the list? Maybe this isn't needed? If you need to
> use ';' in the commands you could stuff that in a shell script.
> 

Good point - I'll write something about how ; will be escaped. I think
it's quite important to have multiple commands to invoke as that will
save users from distributing said shell scripts along with the .fdi
file.

> > usb.version (double)
> 
> I don't recommend doubles for storing versions. 1.1 can't event be
> represented in binary floating point, and exact comparisons on floats
> should never be done.
> 

Ok - I'll make it an integer with a BCD encoding, such that 0x0101 means
USB 1.1 and so forth.

Thanks,
David