O_NONBLOCK for devices with removable media

[Bernd Walter]

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.
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.
But still you are talking about a broken device - replace or fix it
and return to real problems.
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.

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