From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oliver Neukum Date: Fri, 18 Jun 2004 11:28:49 +0000 Subject: Re: Delayed hotplug events Message-Id: <200406181328.56877.oliver@neukum.org> 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > No, I would consider that redundant. If you let events queue up until > > a counter reaches zero, you can guarantee that there's time to generate > > all files being refered to in the event. There's no need to export it. > > > Hmm. I see. But isn't this approach conceptually identical to my patch? > I mean, you're blocking events until a semaphore is set, whereas I'm > dropping events during the critical section and generate them again. No > big change. Conceptually it makes no difference. But queueing events can be encapsulated at the point the tasks are actually spawned. I don't see the possibilty if you have to regenerate events. I may, however, be wrong. > And it doesn't change the main issue, which is that the behaviour of the > hotplug subsystem is changed (i.e. the time when events are sent). > Adding just another attribute doesn't change it, as it's up to the > drivers to generate sysfs attributes. No. An additional attribute is visible. Waiting is not. Assuming that the attribute files are not there as the event is evaluated is _clearly_ wrong. If you delay the events full compatibility is kept. Waiting doesn't change anything fundamentally. It just makes sure that the hotplug subsystem always behaves in a way it may behave currently. Regards Oliver -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA0tH1buJ1a+1Sn8oRArNFAKDkTCKOxrcsheTmWVpcRyFhDY+H+QCdEt+O 7sBLA1aO2QAsmfIbA3OAQJ8=LeBA -----END PGP SIGNATURE----- ------------------------------------------------------- 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