From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Date: Sat, 19 Jun 2004 00:07:33 +0000 Subject: Re: Delayed hotplug events Message-Id: <20040619000733.GD24902@kroah.com> List-Id: References: <40D17ECC.20501@suse.de> In-Reply-To: <40D17ECC.20501@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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