open(2) manpage and O_NONBLOCK

["Jörn Engel" <joern@purestorage.com>]

In open(2), we seem to promise more than the kernel can deliver:
       O_NONBLOCK or O_NDELAY
               When possible, the file is opened in nonblocking mode.
	       Neither the open() nor any subsequent operations on the
	       file descriptor which is returned  will  cause  the
	       calling process to wait.

Clearly you can question whether every last device driver correctly
supports O_NONBLOCK in its open routine.  But even if that was the case,
we still cannot guarantee nonblocking behaviour for open().
get_empty_filp() has to be called for every open() and contains a
blocking memory allocation:
        f = kmem_cache_zalloc(filp_cachep, GFP_KERNEL);

As such I would propose to change the documentation and keep the code.
The open() itself may very well block, but subsequent operations should
not.

J�rn

--
Why do musicians compose symphonies and poets write poems?
They do it because life wouldn't have any meaning for them if they didn't.
That's why I draw cartoons.  It's my life.
-- Charles Shultz