Update on DeviceKit

[David Zeuthen]

On Wed, 2008-05-07 at 20:46 +0200, Lennart Poettering wrote:
> I see you have InhibitShutdown foo here. As I mentioned before I
> believe this functionality belongs in some init system specific D-Bus
> API. But the real problem I see here how does this play with what is
> already in CK regarding shutdown?

No, this is for inhibiting the shutdown of the DeviceKit _daemon_
itself, not the system:

http://hal.freedesktop.org/docs/DeviceKit/DeviceKit.html#DeviceKit.InhibitShutdown

Maybe it needs a better name.

> Where will ACL management/frevoke be handled? And how will policies for
> it be configured?

I expect this will be done via a simple program lika hal-acl-tool that
is invoked by

 - udev rules (device added)
 - ConsoleKit (for adding/removing/changing sessions).

One thing that this doesn't address is D-Bus notification when ACL's are
removed/added and/or (in the future), when revoke(2) is used. We have
the former in HAL. I'm wondering if people interested in this can just
use things like inotify for this? Do you know?

If not, we probably need a simple daemon that can emit signals over
D-Bus. Maybe we need a daemon anyway to avoid spawning a gazillion
copies of this program.

> Will DK create device symlinks, maybe be based on its advanced
> knowledge of what a device actually is? What's the relation between
> your property merging in udev rules? Or will udev talk to dk? I
> remember we talked about that in Hong Kong, any conclusions?

So if we have classifications for a device, these are indeed available
in the udev database. So creating symlinks would be possible. Is it
desirable though? Any concrete examples?

> I see that devices in DK are identified by a "native path". I
> understand that is a runtime-unique sysfs path. Something I've been
> missing in HAL is a more unified approach how to recognize known
> devices. I.e. by unique uuid if they have one, by bus path, by
> vendor/product id, by BIOS tag, and so on and so on. Depending on
> policy, one way to identify a device might be more important thatn the
> others. Any ideas on this? Or is this mostly policy you expect will be
> merged in via the property merging?

Right now there's an array of symlinks to the UNIX device file

http://hal.freedesktop.org/docs/DeviceKit/DeviceKit.html#DeviceKit::DeviceEvent

So for e.g. /dev/sda, you'd have symlinks

/dev/disk/by-id/ata-FUJITSU_MHV2120BH_NW9FT64257U2
/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0

In the disks daemon, we have

http://hal.freedesktop.org/docs/DeviceKit-disks/Device.html#Device:device-file-by-id
http://hal.freedesktop.org/docs/DeviceKit-disks/Device.html#Device:device-file-by-path

which, on Linux, is done by simply checking for the /dev/disk/by-id/
prefix resp. the the /dev/disk/by-path/ prefix. 

I'd expect other subsystem daemons to provide similar things. I'd also
expect users of the raw DeviceKit API (e.g. probably pulseaudio) to do
similar things.

Now, I'm not sure relying on device file symlink names is the greatest
way to pick / uniquely identify a device; ideally we'd merge meaningful
well-defined properties on devices. For example, for audio devices,
pulseaudio would define some properties

 PA_SOUND_CARD_LOCATION
 PA_SOUND_CARD_BIOS_TAG

and provide device information files to populate these. And then access
them via DeviceKit and apply it's policy based on the this result. Since
these things are perhaps not specific to Pulseaudio at all, maybe you
want to define a generic namespace to put these properties in. I expect
we need to have a central registry in DeviceKit-info of well-known
property definitions.

Oh, and maybe you don't want to use such a limiting thing as a fdi-ish
XML file; maybe you really need to run code that investigates the
device. In that case you'd write a udev prober.

Does that make sense?

     David