On Sat, Nov 06, 2004 at 11:59:51AM +1100, Benjamin Herrenschmidt wrote: > On Fri, 2004-11-05 at 16:17 -0800, Greg KH wrote: > > On Tue, Nov 02, 2004 at 06:13:35PM +1100, Benjamin Herrenschmidt wrote: > > > > > > The idea here is to add to the call_usermodehelper() API a plug/unplug > > > semantic (like the BIO). When "plugged", usermodehelper calls would > > > stack up, and would be issued in one shot when "unplugged". By default, > > > at boot, we would be "plugged" until some time, either after the > > > initcalls or at a given initcall level, that remains to be decided. > > > During suspend/resume, we would plug/unplug as well, possibly directly > > > from the PM core, just before starting the driver suspend/resume dance. > > > > No, "plugging" call_usermodehelper() would instantly block your boot > > process, as the hotplug events would not be able to be generated from > > initial device discovery. > > How so ? they would be be queued and issued in batch when userland is > ready... That somewhere after such things as arch_initcalls ! So, you're going to save off all of the memory that is used for the env vars, and then free it up on your own when the queue is "unplugged"? Have you counted how many hotplug events happen on a "normal" boot? My box shows: $ cat /sys/kernel/hotplug_seqnum 991 right after booting. Sure, if you unplug at a early init level, you will not have that many backed up, but I bet you will still have a lot of them pending. Ok, it can be done, but it's going to be very complex. I bet more complex than trying to fix the other problem :) > > This has been discussed a lot in the past on lkml (in the context of > > "plugging" /sbin/hotplug). See the thread there for the end result. > > Do you happen to remember the name of the thread ? sorry, can't remember. thanks, greg k-h
