Johannes Erdfelt wrote:
>
> > I'm seeing how "mount -o devmode=0666 /proc/bus/usb"
> > behaves. Of course it should at last be getting read
> > access always (including GET_DESCRIPTOR and GET_STATUS,
> > which need write permissions!). I'll see how also
> > having "write" permission affects interactions with
> > other driver software, in kernel or in other processes.
>
> I'm readying my patch to load and bind USB drivers from userspace and
That _shouldn't_ affect user space code, right?
Sounds like kernel module loader support.
In any case, it doesn't sound like the stuff you mentioned building
on top of it could address the basic problem: "read" mode permissions
only seems to give permission to access a cached device descriptor.
None of the other standard read-only device operations can be done.
That problem is easy enough to patch, though one needs to be careful
of course. I can start on it next week.
> much of the infrastructure is there to track mode changes on a per device
> basis and restore those when the device is plugged in again (no matter
> what it's USB bus id is). As well as an option to explicitily set
> devices by their idVendor/idProduct should solve this problem.
>
> I plan on working on this after I get the previously mentioned patch
> ready and released.
I'll be glad to see what you're talking about, particularly if it
helps resolve the problems I've seen. Sounds like what had in the
past been discussed as a "usb daemon" functionality, outside kernel.
Wouldn't it need to account for serial numbers, for example?
At this point I'm hoping to find some simple kernel-only approach
that'll support user mode USB applications, and separately experiments
for management of USB characteristics (like power management apps :-),
but will not require a separate user mode daemon. We may be almost
there ... but I'm still looking at what devfs already does.
> > - Everything in /proc/bus/usb/devices should be visible
> > through the .../XXX/YYY files, but I don't know that
> > it's all available there yet.
> >
> > If it is, I'm just not sure how to find it all. For
> > example, the interface binding ioctls don't have a
> > "say who's bound it" mode, just a "bind it now". I'll
> > hope that most of the "T:" line is hub info that I've
> > not parsed yet.
>
> Yes, much of the T: line is hub info and probably isn't useful.
I can see it being useful in a program that's good about displaying
how the bus is really set up. A GUI widget, say.
> I've added an ioctl() to determine the currently bound driver in the
> previously mentioned patch.
That's good for diagnostics. When a user wants to use one application
with a device, it should be easy to at least point towards the culprit
preventing that from happening ... be it that kernel module loader you
mentioned, or some other desktop application.
> The only thing I can think off the top of my head which isn't readily
> available would be the bandwidth numbers. Is this useful to anyone in
> userspace?
>
> Oh, and the speed of the device. I'll add this as well.
As a rule of thumb, if it's been found useful (or at least interesting)
already, by being in "devices" output, I'd assume it'd continue to be so.
> > - Hmm, the devfs include file isn't <linux/usbdevfs.h>
> > but is "/usr/src/linux/drivers/usb/...h" ... if it's
> > going to become very official, that must change. (I
> > noticed that the current rio500 tools ship have their
> > own copy of this kernel header file ... ugh.)
> >
> > The last of these should be a simple patch.
>
> I have to agree. libusb and my devfs patch both have their own headers.
> It would be convenient to have this in include/linux.
Devfs, but not libusb!
> We don't need
> everything in usbdevice_fs.h IIRC, nor do we need anything in the
> existing usb.h. Perhaps we can merge together the parts which userspace
> are interested in and move the kernel specific stuff elsewhere?
At this point in the 2.4 cycle I'd go for minimal changes. But
I like to see cleanup, and sooner better than later.
> > In general, I think that devfs hasn't been getting enough
> > use for its feature set to be considered mature enough to
> > be called complete.
> >
> > Next on my agenda: look at how interrupt endpoints get
> > passed through devfs. There wouldn't be anything written
> > on this, would there?
>
> There's a generic URB interface to usbdevfs which would do this. That is
> for asynchronous transfers. Or, if you want to do it synchronously, you
> can overload the Bulk transfer (since Interrupt and Bulk transfers are
> identical on the wire).
Then "documentation" in <linux/usbdevfs.h> (or whatever it's called) will
need to make clear that "bulk" means "synchronous" (not bulk) and "URB"
means "async". There are four USB transfer modes (command, bulk, interrupt,
iso), and only three ioctls (command, bulk, iso). Talk about confusing...
Did you choose an approach for libusb yet? Do they really both work?
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
