Hello Jeff, Jeff Mahoney: > Attached is the patch I'm going to use for our package. Since I had > intended on sending it to you guys from the start, I preserved the > backward compatibility that I noticed around the code. I've built it > against 2.6.25-rc2-git4 and 2.6.22.17. The patch is against a CVS > snapshot I checked out earlier today. > > Feel free to incorporate it into the project.
Thank you very much. I also have a plan to support a new structure path in struct nameidata when I saw the patch on fsdevel ML. Most of your patch will be merged, but I may prepend 'au_' to some macros or symbols. > As an aside, I noticed that the sysfs interface goes through a lot of > hoops to provide files larger than 4k. In certain cases that's > understandable (multiple PATH_MAX paths specified, for example), but for > the most part I wonder why it doesn't just go with the "one value per > file" mentality that the rest of sysfs uses. The sysfs interface is my headache. Your suggestion which creates a symlink to branch is reasonable. But the same syntax to /proc/mounts is easier for the parser in /sbin/mount.aufs script and others. Additionally I didn't want to consume many inode numbers for such use. The number of branch can be a thousands. That's why I chose /sys/fs/aufs/brs. I am always wondering about converting to /proc from /sys. Some people told me that newer system should select sysfs. But the changes of sysfs interface is painful. How do you think about procfs and sysfs? Junjiro Okajima ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
