On Fri, 2004-11-05 at 17:11 -0800, Greg KH wrote: > 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. Is that really a problem ? > Ok, it can be done, but it's going to be very complex. I bet more > complex than trying to fix the other problem :) Which is ? Move all initializations so that we can run userland way befor arch_initcalls() ? why not before start_kernel() while we are at it ? This is insane. And Power Management has the smae problem. Try calling userland when processes have been frozen or the swap device is off and see what happens... (and that may happen, that is your device may be far enough in the PM tree not to have got the PM request yet, etc...). Well, to be honest, the PM issue is even more complicated since we shouldn't even allow kmalloc(GFP_KERNEL) normally once the PM dance has started, but we have no global way of notifying subsystems & drivers before starting to send the actual PM callbacks, at least not yet. But still, call_usermodehelper is really a 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. Couldn't find it. Ben.
