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).<div>
<br></div><div>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:</div>
<div><br></div><div>The Kernel Driver(s) - these live in kernel-land</div><div>The System Daemon - privileged, so runs as root</div><div>Userspace Agent/Applet - exposes information such as incoming peering, transfers, etc. to the user</div>
<div><br></div><div>For the stack to be at all useful, you need all three pieces. Having one or two has no point at all.</div><div><br></div><div>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:</div>
<div><br></div><div>The Kernel Driver was loaded because we have seen hardware, as soon as we see that hardware.</div><div>The System Daemon was loaded because we had seen the kernel create the bluetooth devices.</div><div>
Userspace Agent/Applet was actually always loaded as part of the session.</div><div><br></div><div>Now there's lots of obvious problems with this approach:</div><div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>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.</div><div><br></div><div><br></div>
<div>So I was curious how these problems would be solved in the systemd world? Reading through the documentation I came up with the following:</div><div><br></div><div>The Kernel Driver is still going to get loaded regardless, because udevd runs modprobe, not systemd.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div>My questions are these:</div><div><br></div><div>1) is the above seen as a problem?</div><div><br></div><div>2) wouldn't it be better if the need could be communicated at all levels, I'm thinking something like:</div>
<div><br></div><div>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.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div>The case of no bluetooth hardware, or no user session, etc. would simply result in none of the above being started ever.</div><div><br></div><div>Better or not?</div><div><br></div><div>
<br></div><div>Scott</div>