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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
