[systemd-devel] Communicating need

[Scott James Remnant]

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.

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.

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.


My questions are these:

1) is the above seen as a problem?

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.

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.

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.


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

Better or not?


Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20110509/a352eadb/attachment.html>