Re: Delayed hotplug events

[Greg KH <greg@kroah.com>]

On Fri, Jun 18, 2004 at 10:12:33AM +0200, Hannes Reinecke wrote:
> Oliver Neukum wrote:
> >Am Freitag, 18. Juni 2004 01:57 schrieb Greg KH:
> >
> >>>On Thu, Jun 17, 2004 at 03:22:07PM -0500, linas@austin.ibm.com wrote:
> >>>
> >>>>By contrast, I can't see what's architecturally unclean about 
> >>>>having device drivers make the call as to when they think they
> >>>>are finally up and ready to go, e.g. by making one puny subroutine 
> >>>>call at the end of thier init sequence.  Why would this be a bad idea?
> >>>
> >>>Because it would be a major architecture change in the middle of a
> >>>stable kernel series.  I'm not going to agree to do that at this time.
> >
> >
> >If you are willing to use a model of a blocking counter you can confine
> >the changes to just the actual hotplug generation. The change is well
> >encapsuled. Drivers not caring about the block/unblock affair simply get
> >the old behavior.
> >It's less elegant than waiting for the specific files, but workable.
> >
> You mean add an additional sysfs attribute which serves as an checkpoint 
> (i.e. if this attribute exists, the initialisation is done)?

That is what udev does today.  No kernel changes are needed to implement
this.

> Neat. Fixing the drivers (or even adding another generic function to 
> drivers/base/core.c) should be pretty straightforward.
> One could even add another ENV which contains the name of the checkpoint 
> attribute; this way it's pretty clear to any script whether it needs to 
> wait or not.

Yeah, we could add this to the drivers if you really need to, but again,
userspace can do it just as easily.

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel