Miklos Szeredi <miklos@xxxxxxxxxx> 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-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
