Do we need hotplug?

Jürg Billeter j at bitron.ch
Tue Aug 16 12:27:02 PDT 2005


On Die, 2005-08-16 at 20:58 +0600, Alexander E. Patrakov wrote:
> There are two solutions discussed not long ago upstream. One is to make 
> an initramfs that captures all early hotplug events, starting from the 
> event with SEQNUM=0, and then replays those events when the root fs is 
> mounted (basically, a better reimplementation of 
> http://bugs.linuxfromscratch.org/show_bug.cgi?id=868 ). This is already 
> available with recent udev releases. In this approach, there's no 
> concept of coldplugging at all. The downside is that races are almost 
> unavoidable.

Why do you think that races are almost unavoidable? I'd be interested in
problematic situations if you have some in mind. paldo uses initramfs
based event replay for more than half a year now. There were some races
in the beginning but AFAIK there aren't any with the most current
approach, at least regarding event handling / module loading.

If you're (or anybode else is) interested in this topic, I could explain
our approach - simplified since event recorder got upstream.

> Another solution is to put event replaying logic into udevstart. The 
> downside is that approach is fragile WRT changes in the correspondence 
> between hotplug variable names and sysfs attributes. Also, there were 
> some objections on the list, like "this is not the task of udevstart, 
> please at least put it into a separate binary". Noe that there's no 
> implementation of this in the existing udev versions.

Not my favourite as the no-initramfs solution only works with kernels
customized for the computer it should run on or very large monolithic
kernels; and it never works when trying to start from usb media - at
least this didn't work some kernel releases ago.

> As for the input susbystem calling /sbin/hotplug directly and not 
> duplicating events on the netlink socket, that's OK if you don't rely 
> upon input module autoloading (e.g. for psmouse).

Maybe this even gets fixed some time ;)

Regards,

Jürg
-- 
Jürg Billeter <j at bitron.ch>




More information about the lfs-dev mailing list