Re: Is configfs the right solution for configuration based fs?

Joel Becker
2008-06-11T09:15:52Z

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
this

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
necessary.

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
things.
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.

Joel

--

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

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127