[systemd-devel] Communicating need

[Lennart Poettering]

On Thu, 12.05.11 09:09, Scott James Remnant (scott at netsplit.com) wrote:

> On Mon, May 9, 2011 at 4:32 PM, Lennart Poettering
> <lennart at poettering.net>wrote:
> 
> > On Mon, 09.05.11 13:13, Scott James Remnant (scott at 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.