Jeff Mahoney:
> Well, sysfs is an easy path once you've embraced the kobject/kset model.
:::
You have succeeded push me into the sea of kobject/sysfs.
I have almost completed rewriting the source files which are,
- the lifetime of sbinfo is handled by kobject unconditinally, which
means sbinfo always have si_kobj member.
- struct attribute and name member of branch is compiled when
CONFIG_SYSFS is enabled.
- most part of sysaufs.c is moved to a new file sysfs.c. sysfs.c is
compiled only CONFIG_SYSFS is enabled.
- the statistic data of aufsd and generic thread is proviede via
/sys/fs/aufs/stat still. But it is required to enable a new
configuration CONFIG_AUFS_STAT and of course
CONFIG_SYSFS. CONFIG_AUFS_STAT is disabled by default.
These will be a part of next Monday release.
> The kobject - kset - kobject relationship seems clear to me. The idea of
> the sbilist and sbilist lock can go away if the kset is used to manage
> the list of objects. Some calls can be eliminated completely because the
> sbi object is passed in the form of the kobject contained within it.
Yes, and I can see that kset already has such list internally. So
eliminating the list and functions for that in aufs will be available.
The important thing is the order in the list. When a user mounted a new
aufs over an existing aufs, ie. on the same mount point, he can see the
files under the new aufs only. From the aufs' point of view, for example
adding/deleting a branch, aufs module (or /sbin/moutn.aufs) has to
decide which super block should be operated, since those two sbinfo has
the same path.
Currently I took an approach depending on the order in the list.
And I am afraid that kset (or future kset) may not keep the expected
order in the list.
But if I can export a similar information via new /proc/mountinfo, this
issue may be able to be gone entirely with /sys/fs/aufs/sbi_*/mntpnt1.
> It's exploiting the C-object oriented nature of the kernel, the way all
> the built-in subsystems do. Well, to a certain extent. The big hurdle is
> that PATH_MAX == PAGE_SIZE on 4k systems. The seq_file hurdles in the
> current code are fun for the idea of extending sysfs, but it's not going
> to happen like that. If 4k isn't enough to describe the data exported,
> the interface needs to change or a new pseudo file system needs to be
> written to export it.
Agreed.
And I am planning to describe explicitly 'the length of full path of a
branch is limited to 4kb - a few bytes'. It means that is a feature of
aufs.
Junjiro Okajima
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
