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 21:00:57 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-103411087818497@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-103406277101783@msgid-missing>
>>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.
>
>
> What needs to be different?
As I suggested, a KFS-only environment variable would be fine.
>> 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.)
>
>
> Wait, why does anyone need to use the usbfs path (what is specified by
> DEVICE= in the usb code)? All of the info that usbmodules used to get
> is now present in DEV_PATH, right? If not, let me know.
I think device speed is still unavailable through KFS, and I suspect
the extra audio descriptor bytes aren't exposed, but other than that
the read-only access modes are about equivalent.
But USBFS lets you interact with the device, and every user mode driver
(or configuration tool) relies on that. Many of them hook up through
hotplug. KFS doesn't; which is why the agents will continue to need
the USBFS path.
There's also the "coldplug" situation. KFS _could_ remember which
devices didn't have hotplug events issued (a device state flag) and
rescan its tree to issue them, after the kernel's come up enough that
/sbin/hotplug can safely be called. Only solving that issue lets us
completely get rid of "usbmodules".
> Also, any reason to keep the DEVFS variable? It's wrongly named, and
> doesn't look like anyone uses it.
Not any longer. But update the docs (on the hotplug website).
- 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 21:00 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
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 [this message]
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-103411087818497@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 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).