Messages in this thread |  | | Date | Sun, 24 Sep 2000 17:54:13 +0200 | From | Marcus Meissner <> | Subject | Re: [linux-usb-devel] USB 2.4 Status/TODO 2000-09-18.B |
| |
On Sat, Sep 23, 2000 at 11:18:15AM -0700, David Brownell wrote: > > > =================================================== > > > USB Status/Problems in 2.4.0-test9-pre2 > > > 2000-September-18 (Rev. B) > > > ==================================================== > > > 6. In Progress > > > > > > . hotplug (PNP) and module autoloader support > > > > I would like to add here that we need a way to find out the relation > > "attached USB device / interfaceendpoint" <-> "linux device (major/minor nr)" > > from user space. Currently the only way to find out this is to use major > > guessing hacks if not impossible. > > Agreed, except that this discovery mechanism needs to handle > devices like network drivers that don't show up on the > filesystem.
Yes. Hmm. Possible taglines for first draft:
type=chardev major=y minor=x type=net name=eth0 ... whatever ...
(we could have multiples of those for one endpoint, think USB joysticks which have /dev/input/jsX and /dev/input/eventX)
> > This is actually the VERY LAST major hurdle to implement USB hotplugging. > > (The rest is easily doable/already done in sample implementations.) > > I'm sure I disagree about that ... :-) > > For example, the networking subsystem has some hotplugging APIs > but no mechanism to use them to call "ifup" or "ifdown" when new > network interfaces arrive, or point-to-point peers finally connect. > I should NOT need to manually "ifup" when I add a network device. > (And not all the USB networking drivers use those nework hotplug > APIs either...) > > Plus, there's no way currently to tell drivers that such-and-such > new device is one that it can handle (or shouldn't handle); the > policy there is all embedded in the kernel. > > There's more I could add, but I'll save it for later!
Well, hotplugging in general should be addressed better. With /sbin/hotplug accepted ... Hmm. Probably thinkable would be using it as general means:
/sbin/hotplug plugin <devicetype> <devicespecific data> (like "usb bus/device")
/sbin/hotplug devattach <devicetype> <devicespecficdata> <kerneldevtype> <kerneldevdata>
with kerneldevtype lik chardev, blockdev, netdev and kerneldevdata being respective data for it.
Dito for devdetach and plugout.
Just some random thoughts.
Ciao, Marcus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |