<div class="gmail_quote">On Thu, May 12, 2011 at 1:09 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;">
<div class="gmail_quote"><div class="im">On Mon, May 9, 2011 at 4:32 PM, Lennart Poettering <span dir="ltr"><<a href="mailto:lennart@poettering.net" target="_blank">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>On Mon, 09.05.11 13:13, Scott James Remnant (<a href="mailto:scott@netsplit.com" target="_blank">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><br></div></blockquote></div><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></blockquote><div><br></div><div>Well, I don't see people replicating all that is in udevd elsewhere and if you want to try to have part of its detection in systemd/upstart, you'll end doing it sooner or later, even if it does not look like doing it now. Disks, Filesystems, USB and Network came to mind as likely cause of extra needs to handle most cases. Maybe Kay can list them here.</div>
<div><br></div><div>But I do agree there is room for improvement, how about doing these improvements in udevd itself? If we can prioritize the devices, or maybe do some short-cuts for simple cases we'd want to replicate in systemd/upstart, then we could check the feasibility to do them in udevd itself.</div>
<div><br></div><div>See, udevd is not a heavy binary by itself. The rules are also pretty simple. So the bottleneck likely is not in having udevd or communicating with init/pid1 itself.</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 class="gmail_quote"><div class="im"><div></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,<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><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></blockquote></div><div><br></div><div>Well, maybe you didn't get the activation part or you're trolling :-)</div><div><br></div><div>As I said in my mail about the bluetooth part, the problem with kernel modules is that "you don't know what's in there until you look in there". If you don't have usb subsystem you can't know an usb sound card may be there :-D Same for audio device on bluetooth on usb, etc.</div>
<div><br></div><div>And while upstart was indeed all about "events" (at least 3 years ago it was), systemd provides multiple ways to handle services, not just socket activation, but timers, various conditionals (paths, directories...) and events. You used to force one direction in the graph, we offer both.</div>
<div><br></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>