O_NONBLOCK for devices with removable media

[victor cruceru]

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:
> > In conclusion:
> > any difference between open with O_NONBLOCK and open without it for this
> > kind of devices?
> > Because man 2 open says:
> > 
> ----------------------------------------------------------------------------------------------------
> > If the O_NONBLOCK flag is specified and the open() system call would 
> result
> > in
> > the process being blocked for some reason (e.g., waiting for carrier on 
> a
> > dialup line), open() returns immediately. The descriptor remains in non-
> > blocking mode for subsequent operations.
> > 
> ----------------------------------------------------------------------------------------------------
> 
> Then make it always fail for disk devices.


This is not a solution. 

I really don't know what you expect to win with this.
> There is no other choice.




There are many short time blocks you won't noice, e.g. openeing a
> 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).

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

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).

> On 8/1/05, Bernd Walter <ticso at cicely12.cicely.de> wrote:
> > >
> > > On Mon, Aug 01, 2005 at 09:41:30PM +0300, victor cruceru wrote:
> > > > Well, if you are doing this from a daemon (multiplexing a lot of 
> events)
> > > > which is blocked in this open syscall, even 1 second is not 
> reasonable.
> > > In
> > > > my case it is something more than 30 of seconds (again, on a 5.4box).
> > > I'll
> > > > give it a try on FreeBSD 6. I'm currently investigating if there is
> > > > something like TEST_UNIT_READY (for both ATAPI and SCSI) which can 
> be
> > > issued
> > > > on a control device (i.e. /dev/ata)
> > >
> > > What do you expect it to do?
> > > Ask the device about the state or always fail, because it is not
> > > allowed to ask the device?
> > > In your case you have a broken device, this isn't much of an argument.
> > > A resonable reply time for a USB device would be less then 10ms.
> 
> --
> B.Walter BWCT http://www.bwct.de
> bernd at bwct.de info at bwct.de


Thanks
victor cruceru