On Fri, Feb 20, 2015 at 7:34 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> Assorted stuff from this cycle. The big ones here are multilayer
> overlayfs from Miklos and beginning of sorting ->d_inode accesses out from
> David.
So I've pulled this, but quite frankly, I think I will unpull it again
unless you actually state *what* the advantages of this pointless
series of endless patches are.
There is absolutely no sane reason to use this crap, as far as I can
tell. The new "fs_inode_once()" thing is just stupid. It's named for
what it does, not *why*, and there is no hint to the filesystem as to
why it should use "fs_inode_once()" vs "fs_inode()".
Now, that was true in the "bad old days" when we just used
ACCESS_ONCE(dentry->d_inode) too, but at least in that old model we
don't have some idiotic wrapper around it.
Dammit, if we add wrapper and "helper" functions, they should *help*,
not confuse. This thing is just badly named, and there is no actual
real explanation for why it exists in the first place, nor for when to
use one or the other. There is just an endless series of patches with
pointless churn.
And no, that "explanation" in commit b717805b3c8b is not an
explanation. Why should filesystems have to know/care. Any use of
"fs_inode()" clearly does *not* specify upper/lower, so what the f*ck
is the advantage of that helper wrt just making the rule be that
"dentry->d_inode" is that unspecified thing.
Explain it, or that crap gets undone.
I'm annoyed, because shit like this that comes in at the end of the
merge window when everybody and their dog sends me random crap on the
Friday afternoon before the merge window closes is just annoying as
hell.
Yes, I work weekends too, but there is really *no* excuse for
last-minute pull requests that don't have good explanations for them.
Explanations for why they are last-minute, and explanations for why
they exist at all and why I should waste my Saturday on pulling them.
Today has been a huge waste of time for me, and reading through this
was just the last drop.
Linus
--
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
