[systemd-devel] Communicating need

[Lennart Poettering]

On Mon, 09.05.11 13:13, Scott James Remnant (scott at netsplit.com) wrote:

> 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.

Well, systemd allows you to do such a thing, but I don't think we want
this really.

> But the Userspace Agent/Applet is again going to get started
> regardless;

Actually no, the plan is to pull in the agent by the hw as well. That
basically means the bus name/socket are always established. The system
daemon and session agent are both pulled in by the hw, or when a
bt-using app is manually started by the user.

Making systemd available for the session is what we plan for F16. As
soon as that is in we can fully implement this scheme.

> 1) is the above seen as a problem?

I don't think so, because ideally the agent wouldn't run either, as
pointed out 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.

This would be kernel 2.2 style module loading? I think that makes sense
only for very few devices, mostly static singleton, even virtual devices
only.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.