methods!

[David Zeuthen]

Hey,

So I finally found some time for implementing methods on hal device
objects. I've committed the code to CVS HEAD but it's a first cut so it
may need a little bit of extra work. Basically, to recap, the idea is to
use device information files to tag a device object about what
interfaces it exposes.

 - info.interfaces is a strlist of the interfaces that is implemented
   apart from org.freedesktop.Hal.Device

 - <ifname>.method_names is a strlist of the methods on the interface
 - <ifname>.method_signatures is a strlist of the D-BUS signatures of
   the methods
 - <ifname>.method_execpath is a strlist of the binaries to invoke

There's the following conventions

 - Binaries are launched with properties in the environment (e.g.
   HAL_PROP_name=value) just as with addons and callouts

 - Incoming method parameters (we only support primitive types) is
   passed in string form on stdin (to e.g. ensure integrity so you
   can safely pass e.g. passwords)

 - Methods always return a UINT32 which is the exit code of the
   process launched

 - Binaries can throw D-BUS exceptions by writing two lines to stderr

I believe this should satisfy our goals and work with both the LUKS
crypto-setup and e.g. power-management. 

Here's a screenshot of me invoking two methods

 http://people.redhat.com/davidz/hal-methods-take-1.png

with the daemon chatting as well. I hope it makes sense :-)

For this to work I've used the .fdi file attached (put it in fdi/policy/
10osvendor/10-power-mgmt-policy.fdi) and two scripts foo.sh and bar.sh
(adjust the path in the .fdi file) which is also attached.

I haven't committed any of these files as the interfaces need a bit more
design. It should be easy enough though. The idea here is that different
OS vendors / distros can patch these files to point to the appropriate
(wrapper) scripts / binaries used to e.g. suspend the machine or set up
a crypto volume. 

Of course, these (wrapper) scripts must have identical syntax and
semantics, e.g. take the same methods, do the same thing (conceptually)
and throw the same exceptions. This is very important as this is in fact
an ABI that desktop apps such as gnome-power, gnome-vfs, Nautilus, KDE
should rely on. Further we need to keep the ABI stable.

About security: the idea here is to properly lock down security through
D-BUS so e.g. only console users are allowed to invoke them. Oh, distros
like Debian may use 'plugdev' group membership instead and distros like
Fedora may require e.g. certain SELinux security contexts.

I'll follow up later (this week hopefully) with specific API's for
Volume and System-wide power management. First of all I need to update
the spec with these and other details before I forget how it works :-)

Comments welcome.

Cheers,
David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 10-power-mgmt-policy.fdi
Type: application/x-extension-fdi
Size: 3047 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/hal/attachments/20050712/52f881ae/10-power-mgmt-policy.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo.sh
Type: application/x-shellscript
Size: 225 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/hal/attachments/20050712/52f881ae/foo.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bar.sh
Type: application/x-shellscript
Size: 227 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/hal/attachments/20050712/52f881ae/bar.bin
-------------- next part --------------
_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal