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

[Artem Kachitchkine]

> hald will only broadcast the signal DeviceAdded(object_path udi) and
> clients will have to GetAllProperties(udi) to actually discover that
> volume.label='naughty pix'...

Excellent!

> So, to recap, the proposed solution is to basically to only filter all
> methods in the hald process. This would solve everything I think, and
> it's a pretty simple modification to hald. Would something like this
> work? 

Functionality wise, yes. I'll have to think this through in terms of
scalability and performance though.

> Of course, depending on how much virtualization (ranging from e.g.
> chrooted jails to things like Xen and VMWare) you want to use there's
> other options such as the obvious one of running separate copies of the
> system bus and hald in each context [2]. 

Jails and Zones are much lower level virtualization technologies, Xen
and VMWare are lower still.

> chroot's for each session would work equally well since for each session
> you would have a system bus daemon listening at the UNIX domain socket
> at the well-know address /var/run/dbus/system_bus_socket. 
> 
> Of course, other constraints of your setup may not allow chroot's, I
> don't know, however in that case I would just patch libdbus so
> dbus_bus_get (DBUS_BUS_SYSTEM, &error) connects to the right socket.

Chroot'ed environment would require copies of shared libraries, 
configuration files, etc. My virtual contexts are dynamically created 
and removed and that would be unacceptable overhead.

Thanks for the insights, David,
-Artem.
_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal