O_NONBLOCK for devices with removable media

[Bernd Walter]

On Mon, Aug 01, 2005 at 10:44:46PM +0300, victor cruceru wrote:
> See below.
> 
> On 8/1/05, Bernd Walter <ticso at cicely12.cicely.de> wrote:
> > 
> > On Mon, Aug 01, 2005 at 10:04:25PM +0300, victor cruceru wrote:
> > device requiring GIANT or any other lock.
> > You can't open any kind device without a risk to block for a very
> > short time.
> 
> 
> It is OK if this is short (10-20 ms).

Well - you have an USB frame every ms, so you can have multiple
transactions in that time.
One can really expect a device to react within that time.

> But still you are talking about a broken device - replace or fix it
> > and return to real problems.
> 
> 
> Yes, this it is maybe true, but why to block in a driver if the user told 
> not to do it?

Because progammers asumed non broken devices?

> On the other hand all the HW is broken somehow... So this O_NONBLOCK should 
> be a way to deal with this kind of silly devices.

Yes, ut USB devices are sometime horribly broken.
It is really the question if we want workarouds for all and everything
possible.
Theoretically you can have a short timeout for such a request, but its
complicated to handle USB timeouts for umass devices - you need to
resync the whole transmission channel, which efefctivly is very much
like a device reset.
AFAIK these kind of resets are done in sync, so you still would block
just to do the reset, which take seconds.
On the other hand this would non-block the open call, but still not
open the device, so you just stop the application from using it.

> Really - a disk should know if it is ready or not and I won't call
> > it blocking if you ask a disk about it.
> > 
> > If you want a workaround then fork another process opening the device
> > for you and passing the descriptor back to you via domain socket.
> 
> 
> This is too complicated to be useful. Maybe to spawn a thread - this is also 
> too complicated for getting the capacity of a damn media (this is my 
> situation).

This is less complicated than a kernel workaround and it even allows
to use the device.
But yes, it's still evil.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd at bwct.de                                  info at bwct.de