<div class="gmail_quote">On Mon, May 9, 2011 at 4:32 PM, Lennart Poettering <span dir="ltr"><<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>></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>
> The System Daemon seems to be where systemd is much more clever; a Bluetooth<br>
> device unit would "want" the System Daemon, but that could be joined with<br>
> socket/D-Bus Activation right? So the presence of the device creates the<br>
> socket, but doesn't start the daemon until an actual connection from a<br>
> Userspace Agent/Applet arrives.<br>
<br>
</div>Well, systemd allows you to do such a thing, but I don't think we want<br>
this really.<br>
<div class="im"><br></div></blockquote><div>Let me give you another example, then. I'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's more than that.</div><div><br></div><div>When we start the X server it enumerates the "udev known" 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't think there'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'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 "activate" the probes on those devices (and even load modules if necessary - though for us they'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">
> 2) wouldn't it be better if the need could be communicated at all levels,<br>
> I'm thinking something like:<br>
><br>
> Moving module loading from udevd to systemd would mean we don't *have* to<br>
> 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 "on activation" whereas you seem to be arguing for "on event" here ;-) I thought systemd was all about the former, whereas Upstart was all about the latter :p</div>
<div><br>Scott</div></div>