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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 11 Jun 2008 02:04:08 -0700
From:	Joel Becker <Joel.Becker@...cle.com>
To:	"Luis R. Rodriguez" <mcgrof@...il.com>,
	linux-wireless <linux-wireless@...r.kernel.org>,
	linux kernel <linux-kernel@...r.kernel.org>,
	Greg KH <greg@...ah.com>,
	Satyam Sharma <ssatyam@....iitk.ac.in>,
	Felix Fietkau <nbd@...nwrt.org>,
	Al Viro <viro@....linux.org.uk>,
	"H. Peter Anvin" <hpa@...nel.org>
Subject: Re: 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
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@...cle.com
Phone: (650) 506-8127
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/