new locking API
david at fubar.dk
Tue Mar 27 12:00:31 PDT 2007
On Tue, 2007-03-27 at 19:29 +0200, Kevin Ottens wrote:
> > If that's the case, then it's a bug that the latter interface don't
> > check on locks from other interfaces. This is all fine and intentional;
> > an interface may want to track locks on other interfaces and even other
> > device objects (e.g. the Volume locks track the Storage lock on the
> > originating storage device).
> Ok, that's fine with me then. Maybe that's a point to clarify in the spec
> though? It wasn't that obvious to me, moreover that means that this kind of
> behavior will have to be described on a case by case basis for each possible
It already says
Note that certain interfaces will also check whether other locks
are being held on other device objects. This is specified on a
per-interface basis in Chapter 5, D-Bus interfaces.
and the Device.Volume docs already says
If a volume originates from a storage device (and all volumes
do), it also is checked whether the caller is locked out of the
org.freedesktop.Hal.Device.Storage interface of the originating
storage device. As a corollary, it is sufficient to just either
a) lock the storage device; or b) globally lock the
org.freedesktop.Hal.Device.Storage interface if one wants to
lock out callers from mounting volumes from either a specific
drive or all drives.
For the record, I've just added this to the Device.Volume.Crypto docs
For objects implementing this interface, it will also be checked
if the caller is locked out of the Volume interface on the
device (and per the section called
“org.freedesktop.Hal.Device.Volume interface” this includes
checking whether the caller is locked out of the
org.freedesktop.Hal.Device.Storage interface for the storage
device that the volume originates from).
Any ideas to make this any more clear? I take patches!
More information about the hal