linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: Delayed hotplug events
Date: Thu, 17 Jun 2004 18:09:30 +0000	[thread overview]
Message-ID: <20040617180930.GB18134@kroah.com> (raw)
In-Reply-To: <40D17ECC.20501@suse.de>

On Thu, Jun 17, 2004 at 01:21:48PM +0200, Hannes Reinecke wrote:
> Hi all,
> 
> currently we have the problem that the driver core might send out 
> hotplug events even though the initialisation of a device has not been 
> finished; worse, we might get an "add" followed by an "remove" event if 
> the device fails to initialise properly, with the corresponding device 
> never appearing in sysfs properly.

Exactly, that is why udevd handles the reordering of hotplug events.  It
seems that suse is not using udevd, and hence needs to handle these out
of order events somehow :)

> This is due to the design of the driver core:
> a call to device_register will trigger a hotplug event, but any sysfs 
> attributes which are added _after_ device_register() will in fact 
> created after the hotplug event has been triggered.

This is a known "issue", nothing new here.

> For the unbelievers, look at
> drivers/scsi/scsi_sysfs.c:scsi_sysfs_add_sdev().  This leads to all
> sorts of nasty race conditions and waiting loops in the hotplug
> agents.
> 
> To solve this I've wrapped up a patch for delaying / suspending hotplug 
> events until they are explicitely enabled again.

Nope, solve this in userspace, not with a patch like this.


> As an example of how it should be used I've patched 
> drivers/scsi/scsi_sysfs.c:scsi_sysfs_add_sdev(), so that the device 
> "add" event will now be triggered only _after_ the device has been 
> initialised properly, including all sysfs attributes.
> 
> Is this approach feasible or am I completely off kilter here?

Off kilter :)

> And if the latter, how should it be solved properly?

In userspace, with things like udevd and just simply sleeping for a
short ammount of time to allow the kernel to catch up to userspace :)

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

  reply	other threads:[~2004-06-17 18:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-17 11:21 Delayed hotplug events Hannes Reinecke
2004-06-17 18:09 ` Greg KH [this message]
2004-06-17 19:56 ` Oliver Neukum
2004-06-17 20:22 ` linas
2004-06-17 23:29 ` Patrick Mansfield
2004-06-17 23:39 ` Greg KH
2004-06-17 23:40 ` Greg KH
2004-06-17 23:57 ` Greg KH
2004-06-18  7:44 ` Oliver Neukum
2004-06-18  8:12 ` Hannes Reinecke
2004-06-18  8:47 ` Oliver Neukum
2004-06-18  9:32 ` Hannes Reinecke
2004-06-18 11:28 ` Oliver Neukum
2004-06-19  0:07 ` Greg KH
2004-06-19  8:16 ` Oliver Neukum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040617180930.GB18134@kroah.com \
    --to=greg@kroah.com \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).