Messages in this thread | | | Date | Thu, 4 Jul 2013 23:50:33 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [PATCH v4 04/12] auto-fs: rename d_count field of dentry to d_refcount |
| |
On Thu, 4 Jul 2013, Linus Torvalds wrote:
> On Thu, Jul 4, 2013 at 7:47 AM, Waiman Long <waiman.long@hp.com> 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..
And all of this can sanely be done with coccinelle. Julia will certainly help to get the scripts right.
Thanks,
tglx
| |