[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <12393.1427467357@warthog.procyon.org.uk>
Date: Fri, 27 Mar 2015 14:42:37 +0000
From: David Howells <dhowells@...hat.com>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: dhowells@...hat.com, viro@....linux.org.uk,
"linux-unionfs@...r.kernel.org" <linux-unionfs@...r.kernel.org>,
Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 12/15] VFS: Add owner-filesystem positive/negative dentry checks
Miklos Szeredi <miklos@...redi.hu> wrote:
> I think this is confusing as hell, there needs to be more consistency
> in the naming. E.g. d_backing_is_positive() vs. d_is_positive(). I
> know it's the other way round now, but only with a few users.
Yeah. The problem is that all of:
__d_entry_type()
d_is_miss()
d_is_whiteout()
d_can_lookup()
d_is_autodir()
d_is_dir()
d_is_symlink()
d_is_reg()
d_is_special()
d_is_file()
d_is_negative()
d_is_positive()
refer to the 'backing' inode (if there is one) in the case that you have a
unionmount and the top dentry's ->d_inode is NULL. (Well, technically, that
doesn't happen in the case of directories)
Of course, if we decide we aren't going to do unionmount, certain things
become simpler.
> Also a separate include file might help, that needs explicit including to
> get the "backing" variants
I would like to see a 'for fs implementer' header and a 'for fs user' header
but Al didn't like that last time I suggested it.
However, it doesn't help with the naming since there are situations where you
need *both* - eg. overlayfs.
> and which would have big fat warnings all over.
Well, we could argue about which side should have the warnings.
David
--
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