From: Greg KH <greg@kroah.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: [linux-usb-devel] usb-storage bug in 2.6.12-rc3
Date: Fri, 29 Apr 2005 20:01:54 +0000 [thread overview]
Message-ID: <20050429200154.GC2327@kroah.com> (raw)
In-Reply-To: <1114633284.16803.17.camel@daxter.boston.redhat.com>
On Fri, Apr 29, 2005 at 09:35:52PM +0200, Oliver Neukum wrote:
> Am Freitag, 29. April 2005 21:28 schrieb David Brownell:
> > On Friday 29 April 2005 11:23 am, Roman Kagan wrote:
> > >
> > > ... instead of trying to make sure the attributes are available via
> > > sysfs at hotplug time, we can use another means to pass them to hotplug:
> > > we can add a routine, which, when called from the .hotplug function
> > > and given pointers to struct attribute and struct device, would add
> > > environment variable
> > >
> > > SYSFS_attrName=attrValue
> >
> > Color me amused. That was the original way to pass information
> > to hotplug agents ... back then (2.4.0.test10 or so), there was
> > usually no other way to export the relevant data.
>
> Does that mean it was a bad idea? At least it makes sure that
> there are less race conditions.
>
> > I'd rather just guarantee that the sysfs device were fully
> > constructed (attributes and all) before the driver binding and
> > hotplug stages of enumeration started. That's been a problem
> > all along, and that's what those recent changes were supposed
> > to be addressing.
>
> Even if you can make sure they had been set up before the script
> started, how do you make sure they are still around?
You can't guarantee that they will not have been removed, but by at
least saying that "the attributes will be created before you will be
called", you let userspace go a lot faster :)
thanks,
greg k-h
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r
_______________________________________________
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
next prev parent reply other threads:[~2005-04-29 20:01 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-27 20:21 usb-storage bug in 2.6.12-rc3 David Zeuthen
2005-04-27 21:21 ` [linux-usb-devel] " Alan Stern
2005-04-27 23:14 ` Patrick Mansfield
2005-04-28 0:47 ` Kay Sievers
2005-04-28 4:34 ` Greg KH
2005-04-28 10:21 ` Kay Sievers
2005-04-28 13:35 ` E. Oltmanns
2005-04-28 14:15 ` Patrick Mansfield
2005-04-29 14:23 ` E. Oltmanns
2005-04-29 18:23 ` [linux-usb-devel] " Roman Kagan
2005-04-29 19:28 ` David Brownell
2005-04-29 19:35 ` Oliver Neukum
2005-04-29 20:00 ` Greg KH
2005-04-29 20:01 ` Greg KH [this message]
2005-04-29 20:16 ` Oliver Neukum
2005-04-29 20:50 ` David Brownell
2005-04-29 21:07 ` David Zeuthen
2005-05-04 7:05 ` Roman Kagan
2005-05-18 14:19 ` David Zeuthen
2005-05-18 17:03 ` Greg KH
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=20050429200154.GC2327@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).