On Thu, Mar 30, 2000, David Brownell <[EMAIL PROTECTED]> wrote:
> Johannes Erdfelt wrote:
> >
> > 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.
Yes, but it's a bit more than that. Think of it is a USB device manager.
It loads and binds drivers to devices (interfaces actually) and tracks
USB devices and sets permissions accordingly, no matter where it goes.
The tracking code doesn't exist yet, but there are some things that can
be done now with devfsd.
> 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.
Works for me. Changing the permissions on the file allows me, as a user
(not root), send control, bulk, etc messages to the device. I had to set
write permissions to write packets to the device.
That is what you were looking for, right?
Or are you looking for read permissions allows the process to only issue
control messages to get information (only pipes marked as "rcv" or
requesttype with the USB_DIR_IN set)?
That may be difficult. I know some devices are fragile if they receive
control messages at the wrong time. I wouldn't want a regular user to be
able to crash the device.
> > 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?
Yes, it would track serial numbers and in the absence of them, position
on the bus. This will take some development and testing to get right.
You can also set default permissions for devices without classes (0xff
or 0x00 vendor classes) if they don't get a driver bound to them. Or set
permissions based on idVendor/idProduct...
I'm sure there's something that can be done to please the users.
> 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.
What it sounds like you want is security (only x person can talk to y
device) but the permissions to follow the device (no matter what USB bus
id it wants). This will be difficult to do in completely kernel space
since the kernel has no way to store the information necessary to track
the device.
> > 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 see. You are correct. I'm sure something can be created to export this
information.
> > 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.
Yes. I expect a program, such as lsusb, could display this information.
> > 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.
I'll add it at some point if someone else doesn't.
> > 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!
Yes, the libusb headers would stay seperate. I was talking about the
linux.h file in libusb, which is essentially a duplication of
usbdevice_fs.h
I also mistyped devfs. I meant devfsd (my patches) have their own usb.h
header which duplicates some of usbdevice_fs.h
> > 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...
My usbdevice_fs.h has:
#define USBDEVFS_CONTROL _IOWR('U', 0, struct usbdevfs_ctrltransfer)
#define USBDEVFS_BULK _IOWR('U', 2, struct usbdevfs_bulktransfer)
#define USBDEVFS_RESETEP _IOR('U', 3, unsigned int)
#define USBDEVFS_SETINTERFACE _IOR('U', 4, struct usbdevfs_setinterface)
#define USBDEVFS_SETCONFIGURATION _IOR('U', 5, unsigned int)
#define USBDEVFS_DEVICEPROBE _IOR('U', 6, struct usbdevfs_deviceprobe)
#define USBDEVFS_SETDRIVER _IOR('U', 7, struct usbdevfs_driver)
#define USBDEVFS_GETDRIVER _IOW('U', 8, struct usbdevfs_driver)
#define USBDEVFS_ACTIVATE _IO('U', 9)
#define USBDEVFS_SUBMITURB _IOR('U', 10, struct usbdevfs_urb)
#define USBDEVFS_DISCARDURB _IO('U', 11)
#define USBDEVFS_REAPURB _IOW('U', 12, void *)
#define USBDEVFS_REAPURBNDELAY _IOW('U', 13, void *)
#define USBDEVFS_DISCSIGNAL _IOR('U', 14, struct usbdevfs_disconnectsignal)
#define USBDEVFS_CLAIMINTERFACE _IOR('U', 15, unsigned int)
#define USBDEVFS_RELEASEINTERFACE _IOR('U', 16, unsigned int)
6-9 are the new ioctl's I added for my new code, but the rest are in my
2.3.99-pre3 tree. Those should provide all of the functionality that a
kernel driver has.
The CONTROL and BULK ioctl's (0 and 2 respectively) and synchronous
since it's common to use those synchronously.
Anything asynchronous is done via the URB interface and the application
is notified via signals when they complete.
> Did you choose an approach for libusb yet? Do they really both work?
Not yet. I haven't played with the URB code in usbdevfs. usbdevfs, from
working with the code, looks complete. If there's anything lacking, it
looks like it can be added/changed without too much of a headache.
Thomas Sailer did a good job with it.
JE
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
