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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
