> > > > Or, it could go the other way around. If you're scanning /dev/...
> > > > nodes, add a corresponding ioctl to find which USB device is
> > > > involved, and then use the existing USB support to find VID/PID.
> > >
> > > This is very helpful.
> > > We should do this as generic as possible.
> >
> > I find it no less helpful than doing it the other way around, in fact.
> > Both are generic approaches. One of them works well with
> > today's hotplug, which seems healthy to me.
>
> Well, actually no, they are not.
> Working through usbdevfs is limited to usb obviously.
> There are eg. cameras with both, usb and firewire.
I thought this discussion was about scanners? :)
And it's not useful to criticise usb for having an
API that firewire is missing ... again, that's less
helpful than doing it the other way around.
> Secondly going through the device node is easier
The usbdevfs nodes ARE device nodes! Your
(new) scenario was basically teaching specialized
device drivers about things usbdevfs already knows.
That means more specialized code in the kernel...
> With the current model I can do 'chmod 660 /dev/usbscanner0'
> and the issue is settled. You can't beat that for simplicity ;-)
The simplicity comes from having one device, not N.
Given USB, I'd call that oversimplification.
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
