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

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Luis R. Rodriguez <mcgrof@...>, linux-wireless <linux-wireless@...>, linux kernel <linux-kernel@...>, Greg KH <greg@...>, Satyam Sharma <ssatyam@...>, Felix Fietkau <nbd@...>, Al Viro <viro@...>, H. Peter Anvin <hpa@...>
Date: Wednesday, June 11, 2008 - 5:04 am

On Sun, Jun 08, 2008 at 07:28:21PM -0700, Joel Becker wrote:

	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
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Is configfs the right solution for configuration based fs?, Luis R. Rodriguez, (Sun Jun 8, 5:25 pm)
Re: Is configfs the right solution for configuration based fs?, Luis R. Rodriguez, (Tue Jun 10, 4:12 am)
Re: Is configfs the right solution for configuration based fs?, Joel Becker, (Wed Jun 11, 5:04 am)