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)
This message was posted by me on linux-usb in response to David Waite's
concerns about my proposal for USB device allocation. I'm sending to to
linux-kernel, since much of this discussion seems to be taking place on
both lists, and I don't think my proposal (and the subsequent
discussion) made it over there.

Matt Dharm

--
Matthew Dharm InterNIC: MDD94
Engineer Cell: (619) 890-6943
Home: mdharm@one-eyed-alien.net Home: (858) 689-1908
Beep: page-matt@one-eyed-alien.net Beep: (858) 621-8155

I'll scuff my feet on the carpet and zap your nose hairs unless you
TALK mister!! Who put you up to this?
-- Pitr
User Friendly, 3/30/1998

---------- Forwarded message ----------
Date: Wed, 6 Oct 1999 00:41:13 -0700 (PDT)
From: Matthew Dharm <mdharm@one-eyed-alien.net>
To: linux-usb@suse.com
Subject: RE: [linux-usb] Re: USB device allocation

This response to David is quite long, but I hope people will take the time
to read it. Please realize that I don't believe that this is a perfect
solution, but I believe it is pretty good (I think it's the best so far,
but then again, I'm biased). I'm looking for anyone who wants to comment
on what they think of it.

Also, I'd really like comments to be directed at how this system falls
short compared to other proposed alternatives. Sure, all proposals have
their problems. But, with all these options on the table, I think we have
to start comparing them to _each_other_ to decide what's best.

Then again, if you think you have an idea that will work, jump in. That's
what I did. :)

Here goes:

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.

> 2. Computers are already shipping with 2 independant USB ports (i.e. 254
> devices max). And you can always buy four port add-in cards, I am not sure
> that all of these use a singular OHCI controller (the controller is what has
> the 127 device limit). If they have four controllers, there would be a 508
> device limit.

Granted. So what about a server system with 4 UW-SCSI cards, each of
which is full of devices? The current allocation style for major/minor
numbers for SCSI drives limits us to 15 drives. For any set of devices,
we can imagine a case where you have an absurd number of them. I consider
4 USB controllers about as likely as 4 SCSI controllers.... and if that
happens, then manual intervention to assign another major number to USB
seems a reasonable alternative to this.

> 3. You would have to accept that removing a device and reinserting it on USB
> (like, say a zip drive) will not give you the same number. You can hack
> logic making this work with serial numbers, but since devices don't always
> have the same serial number you will be fighting a lost cause.

Perhaps. But if it doesn't have a serial number, then either (a) it
doesn't need one (i.e. mice), or (b) we're going to have to fake it
anyway. After all, if the information isn't there, then we're just not
going to be able to make a decision based on it. Under almost any of the
proposals, a daemon will have to make some type of decision with available
information... I fail to see how this is a shortcoming of my proposal over
any other.

> With the existing computers by Apple that have 254 ports, your method is not
> safe (unless we use a separate major per extra USB controller, ouch). What
> is really needed is a way to lookup and open the file in one guaranteed
> operation, the file descriptorcan report an error on read/write if the
> device goes away right then.

If we can have 254 devices, then either we have to bite the bullet and
pick several major numbers (2?), or use a dynamic filesystem. But is the
trouble involved in using a dynamic filesystem justified in the face of
the extreme case of 254 USB devices attached to a system? Just because
it's possible doesn't mean we have to go so far out of our way to allow
it. Consider this: pick one major number to start with. If the user
wants to support more than one major number worth of devices, then they
can recompile their kernel (or just the module) to designate another major
number to use. If all USB ports draw from the same pool of minor numbers,
then this is still a good solution.

As for the lookup and open in one move.... That's the reason why the
assignment tries to avoid re-using designations for devices. The race
condition here is the same one as using kill -9 on a pid.

Consider the following scenario, which I believe demonstrates how my
solution solves the race condition problem:

1) Computer running, 5 devices attached (usb[0-4])
2) Speakers, on usb0, are removed
3) A disk is inserted, and assigned usb5 (next in order, avoiding
repetition)
3) A request for /dev/speaker, which is symlinked to usb0, is made
_before_ the daemon can react to the removal and insertion event --
note that /dev/speaker is still symlinked to usb0
4) The attempt to open fails, probably with a 'device unavailable'
message, since /dev/usb0 no longer refers to any device on the system
5) The daemon catches up, removing /dev/speaker and configuring the disk.

The key points are as follows:

1) /dev/usb0 becomes invalid for _any_ operation as soon as the device is
removed -- this is a kernel space activity
2) The other usb devices did not change their designation
3) When a new device was added, it choose the next available number for
use, thus avoiding any confusion. Again, confusion exists here only
if you have exhausted the pool of minor numbers. A driver
modification to require us to always keep at least one minor number
free (thus reducing our supported device count by 1) will remove this
race condition at the expense of one device. If we go with that
idea, then we should probably spew messages all over syslog that tell
us to allocate another major number for our USB devices.

This avoids race conditions, allows for easy operation of a user-space
daemon, and avoids dangerous confusion. There is still one place where
confusion is still possible -- a device is added and access is attempted
before the daemon can catch up. That's a pretty small time window. In
that case, the symlink shouldn't exist, so the open will fail.

Again, the point is that nobody access the /dev/usb0 designation unless
they are a USB tool and the user knows what they are doing. This is akin
to someone trying to get a file off of /dev/hda2 -- don't do it, go
through the mount point.

Matt Dharm

> > -----Original Message-----
> > From: Matthew Dharm [mailto:mdharm@one-eyed-alien.net]
> > Sent: Wednesday, October 06, 1999 12:31 AM
> > To: linux-usb@suse.com
> > Subject: Re: [linux-usb] Re: USB device allocation
> >
> >
> > Hrm... a slightly different take on the problem...
> >
> > It was originally proposed (that is, the proposition which really kicked
> > this thread of discussion off) that we have a major number for USB
> > devices, and then assign the minor numbers in blocks to different types of
> > devices (i.e. a range for printers, a range for ACM, etc).
> >
> > My understanding (and maybe I'm smoking crack here) is that there are only
> > 127 devices allowed on a USB tree, and minor numbers go all the way up to
> > 255. So, why not simply have devices accessed by their device number?
> >
> > That is to say, the first device on a USB tree is /dev/usb0. The next is
> > /dev/usb1. Our little user-space daemon will simply provide symbolic
> > links between, say, /dev/mouse and /dev/usb0 (if that's proper). Minor
> > numbers are assigned by some sensible system (i.e. first-come
> > first-serve, or perhaps some topology based thing).
> >
> > My initial look at this idea is that it might create some kind of
> > race-condition, if the device known as /dev/usb1 suddenly became known as
> > /dev/usb0 without anything actually happening to the device (but instead
> > other devices around it changing). So, as long as a device, when plugged
> > in, is given a minor number, and that number doesn't change unless _that_
> > _device_ is removed and re-inserted, we should be clear of race
> > conditions. It might be necessary to add the restriction that we try to
> > re-use minor numbers as infrequently as possible (like process ID
> > assignment does).
> >
> > A special /dev/usbinfo entry can be used to pass event data from kernel
> > space to user space in some useful format, to drive the user-space daemon.
> > Heck, with an entire major number, we could have hundreds of paths for
> > information to flow from kernel space to user space, all relating to USB.
> > Topological info, device info, descriptors, statistics, etc. could all be
> > sent on separate minor numbers.
> >
> > This solution has several advantages, as I see it:
> >
> > 1) It provides for low-level access to each USB device
> > 2) It allows easy operation of high-level device names (as symlinks)
> > 3) It leverages the existing solution (the /dev filesystem)
> > 4) It eliminates contention for minor numbers (totally, as I see it)
> > 5) It eliminates the need for a dynamic filesystem
> >
> > #4 and #5 are the biggest gain from my point of view. This will require
> > that USB devices which are not supposed to present a /dev entry do so, but
> > that entry could simply return a line of text that says "Go away. We
> > don't do char interfaces".
> >
> > Comments?
> >
> > Matt Dharm
> >
> > --
> > Matthew Dharm InterNIC: MDD94
> > Engineer Cell: (619) 890-6943
> > Home: mdharm@one-eyed-alien.net Home: (858) 689-1908
> > Beep: page-matt@one-eyed-alien.net Beep: (858) 621-8155
> >
> > It was a new hope.
> > -- Dust Puppy
> > User Friendly, 12/25/1998
> >
> >
> > --
> > To unsubscribe, e-mail: linux-usb-unsubscribe@suse.com
> > For additional commands, e-mail: linux-usb-help@suse.com
> >
>
>
>

--
Matthew Dharm InterNIC: MDD94
Engineer, Qualcomm, Inc. Cell: (619) 890-6943
Home: mdharm@one-eyed-alien.net Home: (858) 689-1908
Work: mdharm@qualcomm.com Work: (858) 651-7649
Beep: page-matt@one-eyed-alien.net Beep: (858) 621-8155

How would you like this tie wrapped around your hairy round head?
-- Greg
User Friendly, 9/2/1998


--
To unsubscribe, e-mail: linux-usb-unsubscribe@suse.com
For additional commands, e-mail: linux-usb-help@suse.com


-
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.229 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site