On Thu, Jul 4, 2013 at 7:47 AM, Waiman Long <waiman.long@xxxxxx> wrote:
>
> I could change patch 3 so that I keep the d_count name, but #define
> d_refcount to d_count. In that way, I can do piece-meal changes without
> breaking the build. Alternatively, I could collapse patches 3-11 into a
> single big patch which will be harder to review.
Since there are many fewer d_count users than there are d_lock users,
I think collapsing things is the right thing to do.
That said, I think Al is right that for all those filesystem uses, we
might actually be much better off with a helper function looking at
d_count, with no macros etc, since they are purely about reading the
count.
So maybe the right thing to do is to add a
static inline int d_count(struct dentry *dentry) { return dentry->d_count; }
helper function *first*, and just say "filesystems should never access
d_count directly", and make the few filesystem users use this helper
function first. That way we can do that as independent commits to
prepare for the switch-over.
Then when the switch-over happens, we just change "d_count" in that
helper function, and it has no filesystem impact at all.
But fs/dcache.c and fs/namei.c that actually really know about and
modify d_count would not use that helper function. It would purely be
about isolating filesystems from these kinds of internal
implementation issues: fs/cache.c and fs/namei.c are all *about* those
internal issues, so they shouldn't be isolated..
Linus
--
To unsubscribe from this list: send the line "unsubscribe autofs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
