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 attachment 90942 [details, diff] 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 attachment 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 attachment 91011 [details, diff] 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 attachment 91028 [details, diff] 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. ***
