On Wed, 9 May 2007, Oliver Neukum wrote: > Am Dienstag, 8. Mai 2007 23:59 schrieb Alan Stern: > > On Tue, 8 May 2007, Oliver Neukum wrote: > > > > > Am Dienstag, 8. Mai 2007 20:59 schrieb Alan Stern: > > > > > 2. I would prefer to have exclusion between open and reset, too. > > > > > > > > Why? I can understand wanting exclusion between read/write and reset. > > > > But there's no obvious reason to make open and reset exclusive. > > > > > > I don't think we'd want mutual exclusion in these cases. In fact > > > read/write > > > should fail in case a device is being reset or has been reseted. > > > > You probably can't prevent ongoing reads and writes from failing. But you > > can delay new reads/writes until the reset is finished, giving them a > > fighting chance of succeeding. > > I don't think we can let them succeed in the common case. Many devices, > eg. modems, printers, ..., have settings which a driver cannot restore, as it > does not understand the io. > In all these cases you have to tell user space that the device has been > reset, which means that io has to return an error code.
This isn't clear. Let's say the device has been reset. Does that mean you want _all_ reads and writes to fail until the next open? Or do you just want the next I/O operation to fail unless there is an open first? Either way implies that you want open to clear the stored error flag. But what if there is a real I/O error -- not a reset? Then you wouldn't want an open to clear the error flag, right? Or would you? The semantics behind this stored error flag thing are far too cloudy for my taste. > When possible I want to avoid this scenario by delay. You could always make skel_open() acquire dev->io_mutex. That would force it to wait until an ongoing reset was complete. Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
