On Wed, 2006-12-13 at 12:25 -0800, Greg KH wrote:
> > Here's a question, then.  Is there a way, after boot, to cause udev to
> > attempt to detect and load modules?  Basically, is there a way to
> > emulate the old behavior of the "coldplug" init script?  This would be
> > very useful for our LiveCD builds, since we've lost the ability to do
> > "nohotplug" on the command line to disable cold plugging.
> 
> You can re-run /sbin/udevtrigger if you want to.

Nice.

> But why do it later?  Why not just let udev do it at the start of boot?

Well, it's pretty simple, we don't always want udev to do it.

> What do you gain by delaying this?

Delaying?  Nothing.

Allowing it to be disabled from the kernel command line is what I am
looking for, here.  Basically, we would disable udev cold plugging by
default.  Then, when we're actually to the point of being a bit more in
control of the system, we check the kernel command line.  If "nohotplug"
is there, we do nothing.  If it isn't, then we'd run /sbin/udevtrigger.
This would "coldplug" the devices, but still allow us to retain
functionality that we used to have with older coldplug versions.

The only issue that we're now facing is that to disable coldplug also
disables their services being auto-started, which means that even if we
do run udevtrigger later, the services for those devices won't be
started.  I'm sure there's some solution to this, but this is really why
I've been dreading newer udev versions going stable.  While the newer
versions are better, no doubt, it means we have to rethink how most of
the auto-detection and configuration is done on the LiveCD.

There have been many times where coldplug tried to load a driver that
caused problems for the user, and being able to disable that driver
being loaded has allowed them to continue to boot.  With a coldplug that
cannot be disabled arbitrarily, we cannot do this.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to