Messages in this thread | | | Date | Mon, 6 Oct 2003 21:34:38 +0100 | From | viro@parcelfa ... | Subject | Re: [RFC 0/6] Backing Store for sysfs |
| |
On Tue, Oct 07, 2003 at 01:31:10AM +0530, Dipankar Sarma wrote: > > What's more important, for leaves of the sysfs tree your overhead is also > > a loss - we don't need to pin dentry down for them even with current sysfs > > design. And that can be done with minimal code changes and no data changes > > at all. Your patch will have to be more attractive than that. What's the > > expected ratio of directories to non-directories in sysfs? > > ISTR, a large number of files in sysfs are attributes which are leaves. > So, keeping a kobject tree partially connected using dentries as backing > store as opposed to having everything connected might just be enough. > It will be looked into.
Note that main reason why sysfs uses ramfs model is that it gets good interaction with VFS locking for free - it just uses ->i_sem of associated inodes for tree protection and that gives us all we need. Very nice, but it means that we need these associated inodes. And since operations are done deep in tree, we don't want to walk all the way from root, bringing them in-core.
However, having them for all nodes is an overkill - if we keep them only for non-leaves, we get all the benefits of ramfs approach with less overhead. Indeed, even if argument of sysfs operation is a leaf node (and I'm not sure that we actually have such beasts), we can always take the parent node and be done with that.
All we need is a) ->lookup() that would look for an attribute (all directories are in cache, so if there's no attribute with such name and ->lookup() had been called, we'd need to return negative anyway). b) sysfs code slightly modified in several places - mostly, sysfs_get_dentry() callers. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |