[systemd-devel] Communicating need

[Gustavo Sverzut Barbieri]

On Thu, May 12, 2011 at 1:09 PM, 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.
>
>
> 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.
>

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.

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.

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.




> > 2) wouldn't it be better if the need could be communicated at all levels,
>> > I'm thinking something like:
>> >
>> > Moving module loading from udevd to systemd would mean we don't *have*
>> to
>> > load the kernel driver, we just know we /can/ should we need to.
>>
>> 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
>

Well, maybe you didn't get the activation part or you're trolling :-)

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.

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.


-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri at gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20110512/8d00363c/attachment.htm>