-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> Jeff Mahoney:
>> The smaller code size applies to both cases, just not entirely as
>> small due to the size of the kobject. It's a pretty small structure,
>> of which we use one per superblock. The scale makes any savings
>> negligible.
>>
>> The sysfs code is all static inline calls, so it carries no footprint
>> when disabled. The use of kobjects removes quite a bit of code and
>> would likely be brought up if it were to be merged upstream.
This post may break proper threading, but I managed to delete the
original message by accident. :(
> You are leading me strongly to the world of sysfs/kobject, and I am
> almost reaching there. :-)
> Here is my another (minor) concern. The sysfs interface changes often
> and it makes me hard to maintain aufs. I am trying to support several
> versions as possible I can, and you may know how hard it is.
> If you know that such changes will be less often than ever, please let
> me know.
Well, sysfs is an easy path once you've embraced the kobject/kset model.
The infrastructure is there, and is optimized away if you don't need it.
The thing is that a lot of what the sysaufs structures do now WRT
reference counting, naming, etc are handled intrinsically with kobjects.
Look at the hoops that au_sbinfo jumps through with naming and reference
counting - and then look how it condenses to a single kobject call after
the conversion. Even the explicit reference counting of kobjects can be
dropped - it's all done by the kobject API.
The aufs setup works perfectly like this:
/sys/fs - kobject, it's not a collection of related things
/aufs - kset, it's a collection of all the aufs superblocks
/sbi_%p - kobject, it's an individual object, but associated
with all the other aufs superblocks
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.
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.
Backward compatibility is a laudable goal, but it's not one that the
mainline kernel really aims for. The project should try to keep in line
with the current upstream kernel and then provide a backward compatible
interface where possible, possibly even in the patch/ directory and not
part of the code. Otherwise, you're coding to an API that's supported
nowhere except by the project itself.
- -Jeff
- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFIDXNnLPWxlyuTD7IRAl8IAKCm1WgvwDQuuud/XZTR/Eeyl0fUxwCdFLCm
hwuDfuwwLot3Os61zg8hxlw=
=Avlu
-----END PGP SIGNATURE-----
-------------------------------------------------------------------------
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
