Still probably worth doing in the long term. In the short term, we could
possibly have a sysctl or personality flag to disable it for the benefit of
broken software. I'm in favour of just letting it break though, to be
honest - it's _already_ possible to trigger the breakage in some
circumstances and making it more reproducible is a _good_ thing.
> If I remember rightly stat() is not interruptible anyway. I don't
> actually argue with the general claim. If I was redesigning unix right
> now I would have no blocking calls, just 'start_xyz' and wait/notify.
stat() would be restartable. With -ERESTARTNOINTR would prevent us from
ever actually returning -EINTR if the signal handler exists and returns.
I suspect open() would actually be more of a pain -- but that we could
probably also restart if we get interrupted as early as the read_inode()
stage.
You don't actually have to redesign the API, although I agree it could do
with it. We could get rid of the bloody silly returning status _and_ length
in one return code from read()/write() etc.
-- dwmw2
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/