Re: pre/post_reset methods for skel

Am Mittwoch, 9. Mai 2007 17:09 schrieb Alan Stern:
> 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?

The second option.

> 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?

Generally, open() means a fresh session. Prior errors must be cleaned.
Errors are reported either
- from the syscall that generates them, which implies synchronous io
- from the next syscall read/write or close, the latter needs flush()
in the driver

> The semantics behind this stored error flag thing are far too cloudy for 
> my taste.

In which way exactly? Currently the skeleton driver does no error reporting
at all, which we can't let stand.
 
> > 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.

That's obviously the best solution. I'll do so.

	Regards
		Oliver

-------------------------------------------------------------------------
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/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel