On Thu, 12.05.11 09:09, Scott James Remnant (sc...@netsplit.com) wrote: > On Mon, May 9, 2011 at 4:32 PM, Lennart Poettering > <lenn...@poettering.net>wrote: > > > On Mon, 09.05.11 13:13, Scott James Remnant (sc...@netsplit.com) wrote: > > > > > 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. > > > > Well, systemd allows you to do such a thing, but I don't think we want > > this really. > > > 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. > > Actually, it's more than that. > > 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). > > 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.
Our entire userspace bootup takes <1s here on an older X300. I think nobody expects that the mouse reacts any quicker than that. But as mentioned elsewhere: if this really is a problem we could modify udev trigger to sort the devices according to some user specific rules before triggering them. That way we can ensure that input gets triggered before network, or whatever else you want to express. But again, I'd really like to see this profiled before look into this. Right now if userspace booting takes < 1s this should be more then sufficiently good for desktop machines, include ChromeOS machines. > > This would be kernel 2.2 style module loading? I think that makes sense > > only for very few devices, mostly static singleton, even virtual devices > > only. > > > 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 systemd is not about lazily doing things. It's about parallelization. That includes that we do things as early as possible so that things are finished when they are actually used. So I think the emphasis should be on priorizing the jobs that are executed in parallel in the best way, but not to serialize them. Of course, specific rules might be slow. If they are we can optimize them, and potentially move them elsewhere, but I think this must be done as result of profiling. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel