Upcoming API change: struct path

[Posted October 30, 2006 by corbet]

The file structure, representing an open file, is passed into the vast majority of filesystem and driver-oriented operations. It contains a couple of useful fields:

	struct dentry		*f_dentry;
	struct vfsmount         *f_vfsmnt;

Josef Sipek recently noticed that in fs/namei.c there is a similar-looking structure defined:

    struct path {
	struct vfsmount *mnt;
	struct dentry *dentry;
    };

He then decided that struct path deserved wider circulation; the result was a series of patches moving struct path into <linux/namei.h> and changing struct file to use struct path in place of the two separate fields listed above.

Of course, there is a certain amount of code in the kernel which is used to struct file in its older configuration; in particular, the f_dentry field is widely used. So this move is an internal API change, which takes a bit of work to fix up. So, when the whole patch set went into 2.6.19-rc3-mm1, Andrew Morton annotated them as "102 patches to do something rather pointless."

So what is the point? When asked, Josef explained it like this:

It's little cleaner than having two pointers. In general, there is a number of users of dentry-vfsmount pairs in the kernel, and struct path nicely wraps it

"A little cleaner" tends to be fairly faint praise for a patch which touches this many files and will affect a lot of out-of-tree code as well. It has made it as far as -mm, however, suggesting that it has a good chance of getting into 2.6.20. Pointless or not, struct path appears to be coming.

Upcoming API change: struct path

Posted Nov 2, 2006 19:49 UTC (Thu) by bronson (subscriber, #4806) [Link]

As Carroll Smith says, if you can't find one way to remove 100 pounds from a race car, you should try to find 100 ways to remove 1 pound.

Small but invasive cleanups like this are smilar. When looked at individually, they just look like pointless liability. Since it takes only a few additional seconds or minutes for a programmer to understand the harder case, how could you ever justify an invasive change like this.

The thing is, little fixes like this add up. Apply one cleanup and very little happens. Apply 100 cleanups and the kernel starts becoming a much nicer place to work.

Just make sure that you apply these cleanups early in the release cycle! When I manage a project, I like to keep track of the cleanups that I can't justify applying. Then, the first week or two after a release, I run though this list and clean things up as best as I can. It helps to keep the code from getting TOO crufty. I guess it's like spring cleaning.

Anyhow, sorry for the rambling. :)