OK, it does what needs to be done regarding atomicity, race conditions, not reusing device numbers, and as you say, it's safe and easy. Sounds good. ~Randy > -----Original Message----- > From: Johannes Erdfelt [mailto:[EMAIL PROTECTED]] > Sent: Monday, April 10, 2000 9:58 AM > To: Dunlap, Randy > Cc: Thomas Sailer; [EMAIL PROTECTED] > Subject: Re: [linux-usb] Re: Suggested dual human/binary interface for > pro c/devfs (fwd) > > > On Mon, Apr 10, 2000, Dunlap, Randy <[EMAIL PROTECTED]> wrote: > > > > Would it make any sense to resurrect my old suggestion/idea > > of using round-robin USB device numbers instead of > > always assigning the lowest number available or is it > > considered bad? It could cause some user confusion also. > > > > Actually I think I like the _concept_ that you are suggesting, > > Johannes. Sounds like a way to keep using low-numbered device > > IDs unless they shouldn't be reused. I'm not so hot > > on depending on an application to do this, though. > > I'd prefer to see another solution that has the same effect, > > but I'm struggling with how to do that. > > > > I'm just thinking aloud (so to speak)...maybe have dual > > modes of device number assignment, default is LOWEST_AVAIL. > > On disconnects, set mode to ROUND_ROBIN. > > This applies to the next connect. After this next > > connect, set mode back to LOWEST_AVAIL. > > Sounds like a kludge, right? And all that it does > > is reduce the window size for the race condition, > > not eliminate it. Using round robin all the time > > is the extreme case of minimizing the window size, > > especially since it's not real likely that someone > > will actually have 127 devices. > > The ROUND_ROBIN idea would make the problem more difficult to trigger, > but it doesn't completely solve the problem. There still is a (very > difficult to trigger) race there. > > The ultimate problem is the applicate needs to inform the USB kernel > code it's still using the device, so it won't try reassigning that USB > id to a new device. > > The easiest way to do this, and track abnormal termination of > a program, > is to open a file and keep it open. I think it's a reasonable > solution, > which is both safe and easy, as long as we mandate to user space > programs that they do this, or they'll have the possibility of races. > > JE --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
