HAL virtualization (was Re: dbus: api or implementation detail)

[Artem Kachitchkine]

David,

Thanks for the timely response.

> I think the direction we're moving towards is to some day deprecating
> libhal in favor of programming languages / runtimes (glib, Qt,
> Java, .NET/Mono) using D-BUS bindings to access HAL.

I see. Here's the reason I asked and was hoping that the HAL ABI is
wrapped in an API.

I'm looking for the best way to run HAL in a virtual context as opposed
to system-wide. Each virtual context is assigned a subset of all devices
available to the system: it could be as simple as a subdir under /dev or
a random mix of special device files; let's call it "devlist". A virtual
context is uniquely identified by a token, an ascii string. Given a
token, one can easily retrieve a devlist associated with it.

A desktop session running in a virtual context has the token set in an
environment variable. The goal is to create an illusion that devlist is
all there is: e.g. lshal and hal-device-manager would only show objects
from devlist, g-v-m will only get signalled for volumes belonging to
the block devices in devlist.

So if the hald patty was sandwiched between the backend bun from below
and some kind of a library bun from above, that would allow me to
encapsulate the virtualization logic into the buns.

The lower half is straightforward: for a hald process running in a
virtual context, the backend would getenv() the token, retrieve the
devlist and feed it into GDL.

The upper half has alternatives. The solution should meet two requirements:

R1. No application source code changes required.
R2. D-BUS messages from different virtual contexts are isolated from
each other. We can't let Alice see that Bob inserted a CD labeled
'naughty pix'.

I guess R2 excludes the scheme with passing the token along with
org.freedesktop.Hal.Manager methods and signals.

I'm not very familiar with D-BUS, so please bear with me. I understand
that I can run dbus-daemon --session and create a named bus, to be used
by the desktop session's apps. The dbus spec says "libdbus automatically
discovers the address of the per-session bus daemon by reading an
environment variable" -the DBUS_SESSION_BUS_ADDRESS variable, which the
apps have to set - which breaks R1, because all current applications use
the system bus.

If there was a library on top of hald, that library would do token ->
DBUS_SESSION_BUS_ADDRESS mapping transparently, say in libhal_ctx_init().

Your thoughts would be greatly appreciated.

-Artem.





_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal