Bugzilla Bug 119989

I've noticed that you can enable true coldplug functionality uncommenting a
line in /lib/rcscripts/addons/udev-start.sh with recent udev releases.

It would be nice if this was functionality was configurable in udev.conf
instead of having to manually edit a shell script.

What is the reason to this being disabled by default?

Yes, it will become a run-time config option soon, as soon as the boot-time
issues are all worked out.

Pardon my ignorance; does this mean that once we get this functionaly in udev
that we will be able to deprecate coldplug and hotplug and use udev for
firmware load (like some distros)?

Re: comment #2:

You can do firmware loading from udev today if you wish, I just haven't
switched
over to it as it requires some other package intregration to make sure it all
works properly.

And yes, it will replace coldplug and hotplug entirely.

Could you be noisy when this feature gets into init scripts? I don't want to
miss it.
thx.

Whats the status of this?

It needs more testing, next release of udev might have some support for this as
the startup
logic has changed (yet again...)

Don't worry, I haven't forgotten about this, but getting rid of all
dependancies on the hotplug package
is taking a higher priority than this.  Once that is done, adding support for
this will be simple.

089 release does the "coldplug" stuff all the time, as that's the way the
other distros do it now.  If it's messy, I could make it a run-time 
config option, but let's see how this works out for now.

yes, please, could we have an option? at least, is it still possible to disable
the new coldplug functionalities of udev 089? I never used coldplug before

+1 for making coldplug optional. On my laptop, I don't want wifi driver to be
loaded on boot, because it then sucks some battery although I usually don't use
it.

A simple yes/no option would be perfect as far as i'm concerned (i don't need
this feature at all), but maybe some would prefer being able to blacklist only
some specific modules, or something like that, i don't know...

(In reply to comment #9)
> +1 for making coldplug optional. On my laptop, I don't want wifi driver to be
> loaded on boot
<snip>

Sorry about the useless comment above, i didn't knew there was already a module
blacklist option. I should read changelogs more often, it was very explicitly
pointed to.

still an issue...

*** Bug 139096 has been marked as a duplicate of this bug. ***

Created an attachment (id=90942) [details]
Adds --no-scan-{block,bus,class} options to udevtrigger

The issue is that udevtrigger is scanning "bus" things which is basically what
coldplug did. This patch adds three options to stop udevtrigger from scanning
buses, blocks and classes, but we only really need bus.

Created an attachment (id=90943) [details]
udev-start.sh with --no-scan-bus option

This is a full drop in replacement for /lib/rcscripts/addons/udev-start.sh that
uses RC_COLDPLUG!="yes" to set the --no-scan-bus option for udevtrigger.
Obviously requires the above patch.

I don't think that udev-start.sh is correct (no options in it).

Care to just attach a patch for it instead?

Oh, and your coding style is a bit wrong for the udevtrigger patch, but I do
like the idea :)

Created an attachment (id=91011) [details]
udevtrigger-skip.patch

Here is a different patch with similar purpose.  It adds a single option, which
can take a comma-separated list of paths to exclude from the udev triggering. 
For instance, this command will skip /bus devices and hdc:

 # udevtrigger --skip=/bus/,/block/hdc

But maybe it's over-enginering, i don't know.  I would be happy with Roy's
solution too :)

Created an attachment (id=91028) [details]
Patch to udev-start.sh for --no-scan-bus

My mistake - I sent up the portage version, not my version. Here's a patch
against the latest in portage.

It removes the udev version check and a few other things. This is good as why
have version checking in the script when the script itself is versioned?

why would udev be able to start a service?

It seems that probing things wouldn't hurt.. or shouldn't hurt...

I'm just curious why my /etc/init.d/net.eth1 starts by itself

(In reply to comment #18)
> why would udev be able to start a service?

So it can successfully hot/cold plug devices.
Like this. Insert network pcmcia card into laptop. udev sees this and loads the
relevant kernel module and then starts the net script to finally bring the
networking up.

Added to udev-096.

I think that coldplugging in udev-096 isn't working correctly.
udev_start.sh has been modified to use the new feature of udevtrigger to
disable scanning of the bus, but I think that the function populate_udev
contains an error. The following lines were taken from udev_start.sh.

populate_udev() {
        # populate /dev with devices already found by the kernel
        if [ $(get_KV) -gt "$(KV_to_int '2.6.14')" ] ; then
                ebegin "Populating /dev with existing devices through uevents"
                local opts=
                [[ ${RC_COLDPLUG} != "yes" && $(udev_version) -ge "96" ]] && \ 
   #### this is the important line
                        opts="--no-scan-bus"
                /sbin/udevtrigger ${opts}
        ..........(cut).............

As you can see from /etc/conf.d/rc, the variable RC_COLDPLUG can enable or
disable coldplugging of rc sevices and NOT of kernel modules:

# Dynamic /dev managers can trigger coldplug events which cause services to
# start before we are ready for them. If this happens, we can defer these
# services to start in the boot runlevel. Set RC_COLDPLUG="no" if you don't
# want this.
# NOTE: This does not affect anything coldplug/udev related, just the
# starting/stopping of the init.d service triggered by coldplug.

With a version of udev <= 094, if you set RC_COLDPLUG="no", then services like
net.eth0 weren't started at boot, but all kernel modules were loaded anyway and
there was no way to disable module coldplugging.
Now with udev-096, if you set RC_COLDPLUG="no" you disable services hotplugging
and also kernel modules hotplugging. In fact this is the result of the line
[ ${RC_COLDPLUG} != "yes" && $(udev_version) -ge "96" ]] &&
opts="--no-scan-bus"
and this is in conflict with the note reported from /etc/conf.d/rc.

I would like to enable kernel modules coldplugging but not services
coldplugging, but now this is impossible.
I think that these (modules coldplugging and services coldplugging) are 2
different features that should be controlled with 2 different variables, for
example RC_COLDPLUG_SERVICES and RC_COLDPLUG_MODULES.

(In reply to comment #21)
>                 [[ ${RC_COLDPLUG} != "yes" && $(udev_version) -ge "96" ]] &&

That looks like a bug as udev version is 96.
Pointless check imho as portage controls the version and the scripts in portage
are versioned. My patch did not have this.

> As you can see from /etc/conf.d/rc, the variable RC_COLDPLUG can enable or
> disable coldplugging of rc sevices and NOT of kernel modules:

That was true at the time of writing - I'll update conf.d/rc to reflect this.

> I would like to enable kernel modules coldplugging but not services
> coldplugging, but now this is impossible.

RC_COLDPLUG="yes"
RC_PLUG_SERVICES="!*"

(In reply to comment #22)
> (In reply to comment #21)
> >                 [[ ${RC_COLDPLUG} != "yes" && $(udev_version) -ge "96" ]] &&
> 
> That looks like a bug as udev version is 96.

Actually it's not a bug, my bad. -ge is greather than or equal to, and I got
confused with -gt, greater than.


> > As you can see from /etc/conf.d/rc, the variable RC_COLDPLUG can enable or
> > disable coldplugging of rc sevices and NOT of kernel modules:
> 
> That was true at the time of writing - I'll update conf.d/rc to reflect this.
> 
> > I would like to enable kernel modules coldplugging but not services
> > coldplugging, but now this is impossible.
> 
> RC_COLDPLUG="yes"
> RC_PLUG_SERVICES="!*"
> 

Fixed in our svn repo, better documentation will appear in baselayout-1.12.2

*** Bug 157735 has been marked as a duplicate of this bug. ***