On Tue, Apr 18, 2000, Richard Gooch <rgooch@xxxxxxxxxxxxxxx> wrote:
> Johannes Erdfelt writes:
> > On Mon, Apr 17, 2000, Richard Gooch <rgooch@xxxxxxxxxxxxxxx> wrote:
> > > Is it possible to have the USB subsystem pick an unused minor, pass
> > > that over a new usbd protocol, and have the usbd daemon mknod(2) using
> > > that number? So unless you have >256 USB "interfaces" hooked in at
> > > once, you'll be OK.
> >
> > If you have one node per interface. The current patch I have is one
> > node per endpoint. An endpoint is a further set of pipes to talk to
> > the device.
> >
> > On the average device, there are 4 or 5 endpoints. Some have as
> > little as 2. Some have as many as a couple of dozen.
> >
> > My development machine, which admitedly has more devices than the
> > average person, would overflow 256 minors.
> >
> > Plus, there are different types of nodes. One which is for the main
> > device, to get all of the cached descriptors for the device. (Some
> > devices don't like being asked for the descriptors after being
> > enumerated)
> >
> > It gets further complicated (which minor points what kind of node on
> > which device, etc).
>
> OK, so basically, to be able to support USB, we either need devfs, or
> we need much larger device numbers. With devfs, many things are made
> easy, without it, you have to jump through a lot of hoops to get
> things to work.
Basically. If the VFS portion was not there, this could be made to work,
but at the expense of lots hoops.
> I think I've got the bigger picture (USB-wise) now, thanks. So I guess
> the next question is how we proceed?
>
> Obviously, you're busy patching the USB subsystem. Are you using the
> void *private_data method of connecting device nodes to device
> instances? IOW, ignore major&minor numbers entirely and use the method
> I advocate in the devfs README? Is this done, or a work in progress?
Yup. We use private_data to point to a struct usb_device * or a struct
usb_endpoint_descriptor * for instance.
We have a separate set of file_operations for the different types of nodes
we want.
The original patch doesn't use character or block devices at all.
I haven't found a reason to use them yet, so I haven't changed it.
> As far as the user-space component goes, you want to have an extension
> to devfsd. How do you see that being maintained and distributed? Your
> earlier patch stuck it into the devfsd source tree, but I wonder if
> that's the way you want to do it? My guess is that the USB extension
> will be changing a lot, as new devices are supported and you come up
> with better ways of doing things. If so, do you really want to have to
> go through me?
I'd suppose that keeping them separate would probably the best for now.
Things will be changing rapidly and I don't want to burden the rest of devfs
or devfsd with USB development for now.
> BTW: how does usbdevfs tie into all this? Can we get rid of it and
> just use devfs instead?
That was the intention. The necessary support wasn't there that we needed,
so we created it. devfs provides a super set of functionality that we need
so making the change is not much of a problem.
I was busy tracking down and fixing some other bugs today so I didn't get
much time to actually work on the coding for moving the rest of the core
to devfs, but work will continue.
JE
|