[lkml]   [2008]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Is configfs the right solution for configuration based fs?
On Sun, Jun 08, 2008 at 07:28:21PM -0700, Joel Becker wrote:
> On Sun, Jun 08, 2008 at 02:25:36PM -0700, Luis R. Rodriguez wrote:
> > I was really interested in looking to start a filesystem based
> > approach for configuration of wireless a while back, an alternative to
> > nl80211 if you will, but I stopped after I was told about some major
> > issues with configfs. I forget the issues raised clearly so I'd like
> I'd love to hear about the issues as well.

Here's a list of "known" issues I hear about with configfs.
These are requests/complaints/etc I have gotten since it was merged.

1) configfs should be sysfs

The argument is that sysfs should somehow support the
user-directed mkdir(2)/rmdir(2) lifecycle of configfs in addition to its
usual functions. This, unfortunately, doesn't work. I sent a pretty
detailed discussion of this to lkml the last time it came up, but here's
a short summary. Number one, I tried this first. It got ugly fast.
Number two, a goal of configfs is a simpler lifecycle than sysfs
(understanding the lifetimes of config items). Adding an additional
mode to the already complicated lifecycle of kobjects directly opposes

2) There needs to be a way to pin a config item

configfs's ->drop_item() operation returns void - if it is
called, your item must deactivate. This is in line with configfs'
user-directed paradigm. However, sometimes another kernel subsystem is
depending on that item - it will crash if the item goes away.
After getting this beaten over my head a few times by good
friends, I realized they were right. configfs now has
configfs_depend_item() to allow subsystems to pin config items when

3) configfs should support large attributes

A configfs attribute can be a maximum of 4k in size. This fits
the simple show/store methods cribbed from sysfs. However, more than
one person has given a good reason for larger attributes, often lists of
This isn't implemented yet, because I haven't come up with a
good way to do it. seq_file works pretty well for the show side, but
there is no seq_write() to match on the store side. I'd love to come up
with a sane semantic and make it work. Consider it a TODO.

Finally, this thread has presented
4) easier definition of items, perhaps with macros like DEFINE_ATTR

I think I have a __CONFIGFS_ATTR() macro, but it's nowhere near
as nice as what sysfs has. This definitely could use some work, making
configfs easier to use.

That's what I have. I don't know if any of these issues were
what you were worried about, Luis.



"In the long run...we'll all be dead."

Joel Becker
Principal Software Developer
Phone: (650) 506-8127

 \ /
  Last update: 2008-06-11 11:19    [W:0.092 / U:1.276 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site