[systemd-devel] Communicating need

Mon May 9 15:27:41 PDT 2011

On Mon, May 9, 2011 at 5:13 PM, Scott James Remnant <scott at netsplit.com>wrote:

> Thanks for your answers so far, I haven't had a chance to fully read and
> digest them yet, but will do so before replying on those threads (if I even
> need to, it's likely your responses are complete in of themselves).
>
> My third question is about communicating need; for this I'd like to outline
> a use case we should all be reasonable familiar with, that of Bluetooth.
> There are a number of components of this stack, all separated by
> ring/privilege for good reason:
>
> The Kernel Driver(s) - these live in kernel-land
> The System Daemon - privileged, so runs as root
> Userspace Agent/Applet - exposes information such as incoming peering,
> transfers, etc. to the user
>
> For the stack to be at all useful, you need all three pieces. Having one or
> two has no point at all.
>

Actually there is no need of an userspace agent/applet in some cases, like
one could setup an automated task. Let's say you want bluez running so
monitor people that is around and log them (ok, lame use case, but you get
it ;-))   Other less crazy examples are bluetooth HID, sound, printers and
similar.

But yes, considering your valid case let's move on.

One of Upstart's mistakes - understandable, it was 2005, we were still
> excited about hotplug! - was to work on the principle that if we could start
> something, we should start something. This reflects its hotplug heritage,
> and even udevd works this way today:
>
> The Kernel Driver was loaded because we have seen hardware, as soon as we
> see that hardware.
> The System Daemon was loaded because we had seen the kernel create the
> bluetooth devices.
> Userspace Agent/Applet was actually always loaded as part of the session.
>
> Now there's lots of obvious problems with this approach:
>
> Userspace Agent/Applet gets loaded whether or not there is Bluetooth
> Hardware in the computer, whether or not there is a Kernel Driver loaded and
> whether or not the System Daemon is installed.
>
> The System Daemon gets loaded whether or not there is a user session; it's
> wasted resources without one, there's no user to authenticate incoming
> peering requests and transfers. (At least the Upstart approach ensures the
> System Daemon doesn't get loaded without a Kernel Driver).
>
> The Kernel Driver gets loaded whether or not there is a System Daemon or
> user session; sure it's small, but it's still a waste of time and effort
> without them.
>
>
> So I was curious how these problems would be solved in the systemd world?
> Reading through the documentation I came up with the following:
>
> The Kernel Driver is still going to get loaded regardless, because udevd
> runs modprobe, not systemd.
>

you can blacklist it if there is no userspace tools to handle it. That would
require some packaging changes to cope, but it is doable.

If it's desirable to load it if there is some user space using it, one you'd
need to add some udev rule to listen for module, check for userspace (dbus
name? but where? all user session bus? or with the user in current seat?),
then rmmod if there is nothing using it.  OTOH, when user starts, it would
be needed to ask some new tool if there is such device and load a module for
it. It's troublesome, but I guess it is doable. But is it worth?

>
> The System Daemon seems to be where systemd is much more clever; a
> Bluetooth device unit would "want" the System Daemon, but that could be
> joined with socket/D-Bus Activation right? So the presence of the device
> creates the socket, but doesn't start the daemon until an actual connection
> from a Userspace Agent/Applet arrives.
>
> But the Userspace Agent/Applet is again going to get started regardless;
> it'll start up, and connect to the socket, activating the Bluetooth Daemon.
> In the case where there is no Bluetooth hardware, the socket won't exist so
> it'll get "connection refused". But you've still wasted the effort of
> starting a bluetooth agent/applet when there isn't any bluetooth
> hardware/support on the system.
>

In this case the socket is the dbus socket, what will not exist is the DBus
name. Today applets handle it by showing a special informative icon, but
they could just die by themselves.

What is not there is some kind of tool to listen for DBus "NameOwnerChanged"
and if the new name match some rule, start the applet. This is easily
doable, likely inside systemd-user-session itself, or by the desktop
environment. And IMO this is useful.

One reason for this to be in the Desktop Environment and not in
systemd-user-session is that different DE will handle this differently.
While in Gnome it is (or used to be) different process for applets, in
Enlightenment we have a shared library loaded. Thus systemd cannot do a
thing, other than communicate the DE... listening to systemd or dbus
NameOwnerChanged will not be much different.

> My questions are these:
>
> 1) is the above seen as a problem?
>

I'd say it's a valid case, but small impact on real world cases. Other parts
of our system are much heavier than the kernel module for sure.  The applet
part may be heavier (due resources like images and GUI), but this is likely
to be handled at their side anyway (see my thoughts above).

2) wouldn't it be better if the need could be communicated at all levels,
> I'm thinking something like:
>
> Moving module loading from udevd to systemd would mean we don't *have* to
> load the kernel driver, we just know we /can/ should we need to.
>

Kay may correct me here, but loading the module is important as it may show
OTHER parts of the system. Bluetooth, for instance, can easily expose new
sound devices, keyboard and mouse. None of these will need applet running.

If you think about buses, you'll only get USB devices if you modprobe
usbcore. Same for PCI... and in a way or another, btusb is similar to it.

> Likewise we therefore know we /can/ load the system daemon, so the socket
> would be created for it, but the daemon itself isn't loaded and the module
> isn't loaded just yet.
>

See above. And for bluez there is no new socket, but a DBus name on existing
dbus socket.

> When the user session starts, we know we /can/ load the userspace
> agent/applet, and since a system daemon also can be loaded, we actually do
> go ahead and start it - it's a leaf of the can tree. It starts, connects to
> the socket which activates the system daemon, but beforehand causes the
> kernel module to be loaded.
>

See above as well, if GNOME listen for DBus NameOwnerChanged it can know
when it should  enable/disable Bluetooth applet.

> The case of no bluetooth hardware, or no user session, etc. would simply
> result in none of the above being started ever.
>

What to do for Bluetooth keyboards, mouse, printer, headset...?

And right now if you don't have hardware you don't get kernel/system daemon,
all you get is an applet.

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri at gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20110509/5957a753/attachment.htm>