[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.1.10.0808121316570.3462@nehalem.linux-foundation.org>
Date: Tue, 12 Aug 2008 13:21:56 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Al Viro <viro@...IV.linux.org.uk>
cc: OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] readdir mess
On Tue, 12 Aug 2008, Al Viro wrote:
>
> you've just lost e.g. -EIO for getdents(). And if you bail out on
> non-zero return value from vfs_readdir(), you are back to -EINVAL
> on full buffer.
Btw, this whole sentence, and the one from your next email seems to really
show a fundamental misunderstanding of the whole readdir() error handling:
> PS: we might get away with both, if we used _positive_ values as well.
> E.g. have getdents() filldir return 1 if we are out of buffer *and*
> have ->previous != NULL (and -EINVAL if we are out of buffer on the
> first call)... And have some other positive constant for "->readdir()
> didn't feel like going all the way to the end of directory".
We *must* handle partial returns by returning "success". And we do,
except for our _confusion_ about ->readdir() returning error and that
somehow "overriding" the fact that it already returned non-errors earlier
through the callback.
All your blathering about "positive values as well" seems to ttoally
misunderstand how readdir() works. We absolutely do *not* need positive
return values, because the fact is, the only positive return value we ever
need is the "we already filled _earlier_ buffers". And that's the one
that we already do.
The fact is, NO ERROR VALUE CAN POSSIBLY MATTER if we already returned one
or more entries to getdents/readdir(). We should return a success value.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists