new locking API

[David Zeuthen]

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

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!

     David