Re: udev-059 and default.hotplug script

[Kay Sievers <kay.sievers@vrfy.org>]

On Sun, Jul 03, 2005 at 02:15:47PM +0200, Marco d'Itri wrote:
> On Jul 03, Kay Sievers <kay.sievers@vrfy.org> wrote:
> 
> > There is no general rule. It depends on your setup and how you organize
> > things on bootup. SUSE does kernel event-replay from initramfs. udevstart
> > and coldplug are not used anymore.
> > 
> > udevstart did dev.d/ also with the old udev versions, so only the
> > hotplug.d/ replacement RUN rules you may disable with matching
> > $UDEVD_EVENT.
> > 
> > But it may also be possible to modify udevstart to replace coldplug.
> > Don't know, you may have a better view, if this is possible?
> This same tought occurred to me before, coldplugging could come for
> free since udevstart already walks sysfs and generates events for the
> PCI and USB devices, but I am not sure about all the possible
> consequences.

But we need to walk through /sys/devices to catch devices there
for modules-load, ..., right? That is not handled by udevstart
currently.

> My first tought about this is that it's too early to mandate using
> initramfs, so udevstart should continue to be fully supported until
> other reasons will make using initramfs mandatory for everybody.

Yes, righ. It is not mandatory to use replay. But it works very nicely
and I expect we all will go that route sooner or later. Time will tell... :)

> My second tought is that I do not understand exactly which events are
> generated and when in these cases, both when drivers are modular and
> statically built in the kernel:
> - initramfs with events replaying

All events are catched and can be replayed. No logic needed, it's all
possible with the normal udev rules without any coldplug-scan or
whatever.

> - udevstart

Handles only devices with a node.

> - coldplugging

Scans for devices to load modules too.

Maybe we can combine udevstart and coldplugging, but someone that will
actually use it will need to help here. I'm expected to concentrate on the
event-replay stuff.

> so I would welcome some documentation about this.
> (The "when" part is very important, because it's crucial to know at
> which point of the boot process the RUN scripts will be started.)

We have an initramfs that stores every event with udeveventrecorder in
the filesystem and when the real root is mounted udevd is started with
the exec_queue blocked. After feeding the events to udevd, the queue
handling is switched on and udevd starts with the very fist events the
kernel has emitted and seamlessly receives and handles all new events
that arrive in the meantime in the queue.

> Did you look yet at my hotplug-light scripts?
> http://www.bofh.it/~md/debian/

Only a short look and it looks great compared to the current ones. But SUSE
does not use the hotplug package, it has it's own version which is highly
integrated into the configuration system.
We are going to revamp major parts and replace a huge part of it.

> > The next major udev version will depend on kernel 2.6.12 and will support
> > fast node creation in the udev daemon itself. _Simple_ rules will be able to
> > handled by the daemon itself. That will hopefully make event-replay fast
> > and easy and be a better approach than udevstart and coldplug.
> Why? How was udev determined to be slower?

On event replay you fire ~800 processes in a few seconds, while most of
these events are simple devices without any further processing. Tests showed
and my coworkers needed to convince me that doing this in-process is much
faster and you save some seconds bootup-time. (using udevstart does not have
this problem, cause it already does everything with only one process)

> I am a bit concerned about increasing complexity and code size.

It's not getting bigger, it will be lot smaller I expect, cause I will
remove a lot of old code and half of wait_for_sysfs, cause this is solved
with kernel changes. It will also be able to work without sysfs for simple
rules, which will make some people very happy.

> (And I am very concerned about the dependency on a kernel newer than the
> 2.6.8 shipped in Debian 3.1, which I fear will make upgrades painful.)

Debian will need to have shorter release cycles than 3 years. :)

The next version will definitely not work with kernels earlier than 2.6.12
and a next HAL version will require that udev version to be functional.
The recent HAL already depends on 2.6.11 anyway.
But I see no problem for Debian to stick with that version, or make some
tricky boot script to decide what udev version to run.
Also I don't see a problem to have official maintence releases on top of
the version before the cut if that is useful.

We have no other option to make progress with our integration work and need
to get rid of the old stuff during the next months to reach that goal.  We
will see big changes in the dynamic hardware handling and all that stuff will
only be possible with recent kernels, udev and HAL versions.

The commercial distributions have definitely no ressources to support so
many options and will just require specific kernel versions to work with
the rest of the system. They just make sure that the systems will run with
recent custom kernels, therefore udevstart will also be supported as long
as it is needed. But support for older kernels will need to be dropped
to keep the packages maintainable if the difference is that big like the
netlink-uevent, the modalias-support, no need to wait_for_sysfs for most
of the events and the $MAJOR/$MINOR in the event env.

Thanks,
Kay


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel