From: David Brownell <david-b@pacbell.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: /sbin/hotplug invocation for USB devices in 2.5.40
Date: Tue, 08 Oct 2002 17:02:59 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-103409912704123@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-103406277101783@msgid-missing>
Greg KH wrote:
> As almost no one noticed, I changed the environment variables that
> /sbin/hotplug is called with in 2.5.40 :)
I look at it just a bit differently ... where previously it only
issued calls for the first interface (typically that's all there is),
now it issues calls for every interface, _plus_ a call for a new kind
of thing never before seen through hotplug, a "usb device".
I really like the "event for each interface" change, though I'd
like it a bit better if we could tell this 2.5+ behavior apart
from earlier ones -- so hotplug agents can act accordingly.
Its that new type of hotplug event that makes recent kernels trigger
syslog messages about "Bad USB agent invocation".
> Now I know this overloads the existing DEVICE usage for USB devices, but
> I think we can determine what do properly (basically just test for
> DEVFS, and if it's not set, then we are looking at the driverfs entry
> for the device.)
I'd rather see these changes:
- This new parameter to every (!!) hotplug event gets renamed to
KFS_DEVICE (assuming that's the new driverfs name).
Hotplug agents will need to access KFS data *and* talk to the
device (and its drivers) using the DEVICE= path. Plus, if this
is present we know we don't need to ask 'usbmodules' to scan
other interfaces for us. (That often triggers other problems.)
- Don't make hotplug calls for USB devices until we have something
for them to do. (Essentially these are a new class of event.)
The example that comes to mind is policy agents using those
events to choose a non-default device configuration. But USB
needs a bunch of work before such things become practical.
I think both of those would be simple changes to make. They'd
greatly improve backward compatibility, while letting us do better
things on Linux Next Generation systems.
> I also created a lot of individual driverfs files for the USB device,
> basically everything that used to be specified by a environment variable
> in the call to /sbin/hotplug, is now a value in a file. So ideally, we
> can get rid of those other variables for the USB call, and just rely on
> the info present in driverfs.
That'd only work if both KFS_DEVICE and DEVICE are simultaneously available.
See above ... :) I wouldn't de-support the other parameters for quite
a while, though it's certainly good to have such improved flexibility.
By the way, what's the cost of a driverfs attribute on a 'struct device'?
Each USB device now has over a dozen of them.
- Dave
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
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:[~2002-10-08 17:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-08 7:32 /sbin/hotplug invocation for USB devices in 2.5.40 Greg KH
2002-10-08 17:02 ` David Brownell [this message]
2002-10-08 17:49 ` Patrick Mochel
2002-10-08 17:55 ` Oliver Neukum
2002-10-08 18:14 ` David Brownell
2002-10-08 18:18 ` Oliver Neukum
2002-10-08 18:18 ` Greg KH
2002-10-08 18:25 ` Greg KH
2002-10-08 21:00 ` David Brownell
2002-10-08 21:17 ` Greg KH
2002-10-08 21:18 ` David Brownell
2002-10-08 21:28 ` David Brownell
2002-10-08 21:39 ` Greg KH
2002-10-09 15:15 ` David Brownell
2002-10-10 20:35 ` 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=marc-linux-hotplug-103409912704123@msgid-missing \
--to=david-b@pacbell.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.