<div class="gmail_quote">On Mon, May 9, 2011 at 5:13 PM, Scott James Remnant <span dir="ltr"><<a href="mailto:scott@netsplit.com">scott@netsplit.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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></blockquote><div><br></div><div>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.</div>
<div><br></div><div>But yes, considering your valid case let's move on. </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><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>
</blockquote><div><br></div><div>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.</div><div><br></div><div>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?</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<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>
</blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>My questions are these:</div><div><br></div><div>1) is the above seen as a problem?</div>
</blockquote><div><br></div><div>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).</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><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></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<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></blockquote><div><br></div><div>
See above. And for bluez there is no new socket, but a DBus name on existing dbus socket. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div></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>
</blockquote><div><br></div><div>See above as well, if GNOME listen for DBus NameOwnerChanged it can know when it should enable/disable Bluetooth applet.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>The case of no bluetooth hardware, or no user session, etc. would simply result in none of the above being started ever. </div></blockquote></div><div><br></div><div>What to do for Bluetooth keyboards, mouse, printer, headset...?</div>
<div><br></div><div>And right now if you don't have hardware you don't get kernel/system daemon, all you get is an applet.</div><br>-- <br>Gustavo Sverzut Barbieri<br><a href="http://profusion.mobi">http://profusion.mobi</a> embedded systems<br>
--------------------------------------<br>MSN: <a href="mailto:barbieri@gmail.com">barbieri@gmail.com</a><br>Skype: gsbarbieri<br>Mobile: +55 (19) 9225-2202<br>