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