Update on DeviceKit

[Lennart Poettering]

On Wed, 07.05.08 03:40, David Zeuthen (david at fubar.dk) wrote:

> This is a simple system service that a) can enumerate devices; b) emits
> signals when devices are added removed; c) provides a way to merge
> device information / quirks onto devices. And that's it. A device is
> identified by a) the native OS-specific path (on Linux a sysfs path); b)
> an optional UNIX device file; and c) key/value pairs describing the
> device. It's a very simple service, a bit like what HAL is today without
> all the probers/callouts
> 
>  http://hal.freedesktop.org/docs/DeviceKit/
>  http://gitweb.freedesktop.org/?p=users/david/DeviceKit.git;a=summary

Some comments:

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?

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

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?

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?

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4