All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.