lkml.org 
[lkml]   [1999]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [linux-usb] Re: USB device allocation (fwd)
On Wed, Oct 06, 1999, Matthew Dharm <mdharm@one-eyed-alien.net> wrote:
> On Wed, 6 Oct 1999, Johannes Erdfelt wrote:
>
> > On Wed, Oct 06, 1999, Matthew Dharm <mdharm@one-eyed-alien.net> wrote:
> > > On Wed, 6 Oct 1999, David Waite wrote:
> > >
> > > > A number of problems though:
> > > > 1. People will need to realize that they are not guaranteed that usb0 will
> > > > remain usb0. If someone unplugs a hub off root with 126 devices tied to it,
> > > > they will probably all get scrambled. So in the end, you need some way to
> > > > make sure that if you want a certain device, you are going to get it. A
> > > > Lookup-then-Check method will work, if it repeats on failure.
> > >
> > > The point is that nobody will directly access usb0 unless they know what
> > > they're doing. People will generally use the symlink for the device.
> > > Also, since the assignment will always roll upwards (like process IDs), if
> > > usb0 is disconnected and a new device connected, the only way that the new
> > > device will get usb0 is if _all_ other usb minor numbers are assigned.
> > > That's a lot of devices, and one very paranoid case. If you have 255
> > > devices (254 attached at any one time), then you know you should be
> > > careful.
> >
> > This sounds like an interesting solution, but I have some questions. How
> > would you merge the 2 sets of ioctl's for the device.
> >
> > There's the set of ioctl's for the USB specific portion of it, then
> > there's the set of ioctl's for the deriver specific (lp, scsi, etc).
> > AFAICT, this isn't going to be easy with the current setup.
>
> That could be a problem. Tho that's a problem with almost all of the
> discussed options for USB device allocation.
>
> First, are there any USB-specific ioctl's? If there are, then we need to
> figure out how to handle those, regarldess of how we assign device
> numbers (my method, statically, or devfs). Suggestions? The first one
> that comes to mind is that the USB-specific ioctls could only operate on
> /proc, or that they are given numerical assignments which are unassigned
> to other ioctl's for most all devices.

This is how it operates now. /proc/bus/usb/dev has all of the USB
devices. You open and use ioctl to send raw commands to the device.

The problem with it now is permissions. I want to send raw commands to
my USB camera. There's no reason for a kernel driver. However, you can
change permissions on /proc files and keep it persistant.

JE


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.186 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site