<div class="gmail_quote">On Mon, May 9, 2011 at 4:32 PM, Lennart Poettering <span dir="ltr">&lt;<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mon, 09.05.11 13:13, Scott James Remnant (<a href="mailto:scott@netsplit.com">scott@netsplit.com</a>) wrote:<br>
<br>
&gt; The System Daemon seems to be where systemd is much more clever; a Bluetooth<br>
&gt; device unit would &quot;want&quot; the System Daemon, but that could be joined with<br>
&gt; socket/D-Bus Activation right? So the presence of the device creates the<br>
&gt; socket, but doesn&#39;t start the daemon until an actual connection from a<br>
&gt; Userspace Agent/Applet arrives.<br>
<br>
</div>Well, systemd allows you to do such a thing, but I don&#39;t think we want<br>
this really.<br>
<div class="im"><br></div></blockquote><div>Let me give you another example, then. I&#39;ve already touched in the other thread on the problem with input devices being delayed by other probing work udev is doing.</div><div>
<br></div><div>Actually, it&#39;s more than that.</div><div><br></div><div>When we start the X server it enumerates the &quot;udev known&quot; input devices on the system, since getting something on the screen is our top priority, the X server comes up before that udevadm trigger (and maybe even before udevd is running - I don&#39;t think there&#39;s a dep there).</div>
<div><br></div><div>Obviously there are no devices, and they are not tagged ID_INPUT by udev, so X sees no devices. It&#39;s not until a few seconds later that the show up - udevadm trigger may take meer hundreds of milliseconds (that sounds cheap to you, expensive to us :p) but it takes udevd many seconds to actually deal with the result.</div>
<div><br></div><div><br></div><div>In my ideal world, the X server starting up and asking for input devices would &quot;activate&quot; the probes on those devices (and even load modules if necessary - though for us they&#39;re built-in), so that the information is delivered in a timely manner.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
&gt; 2) wouldn&#39;t it be better if the need could be communicated at all levels,<br>
&gt; I&#39;m thinking something like:<br>
&gt;<br>
&gt; Moving module loading from udevd to systemd would mean we don&#39;t *have* to<br>
&gt; load the kernel driver, we just know we /can/ should we need to.<br>
<br>
</div>This would be kernel 2.2 style module loading? I think that makes sense<br>
only for very few devices, mostly static singleton, even virtual devices<br>
only.<br>
<br></blockquote><div>Well, that style loading was &quot;on activation&quot; whereas you seem to be arguing for &quot;on event&quot; here ;-) I thought systemd was all about the former, whereas Upstart was all about the latter :p</div>
<div><br>Scott</div></div>