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]

Message-Id: <1213056772.4089.42.camel@moss.renham>
Date:	Tue, 10 Jun 2008 10:12:52 +1000
From:	Ben Nizette <bn@...sdigital.com>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	"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>, Joel Becker <joel.becker@...cle.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 Mon, 2008-06-09 at 11:03 +0200, Johannes Berg wrote:

> Personally, I have a few issues with this:
>  1) why bother with a second configuration interface that we have to
>     maintain, adjust, ...? if we need scriptable access, then make a
>     good userspace tool that is scriptable.

What's the first one, sysfs..?  ioctl (eww..)?  I do think they solve
different problems, both have their place.  IMHO sysfs is forced to do
configuration in some situations where it just doesn't fit.  Prolly 'coz
sysfs have the easy __DEVICE_ATTR kinda macros where as configfs takes
more effort to get flying.

>  2) string-based stuff is often messy, especially the varying attributes
>     like MAC addresses etc. Unless we just use binary files again, which
>     is not very useful again. Take, for example, the monitor flags. If
>     we use the same flags then nobody really knows what's up 
>     (echo 0x3 > mntr_flags?) and if we use strings then we cannot easily
>     ever rename the flag while keeping ABI/API compatibility.

Not sure I see the argument here, why would you want to change the flag
name?  If you decide the old name is stupid then can't you just alias
the old name to the new one?

String handling is always a bit iffy, though it has to be done
somewhere, either in kernel or in your "good userspace tool which is
scriptable".  I'd prefer to have it done once, well, in the kernel and
not have to ship more software than necessary.

>  3) afaik configfs doesn't actually support the mkdir, ... stuff yet
>     that you want for virtual interfaces.

It has all the  mkdir stuff I can think of, can you elaborate?  It
doesn't have the commitable object support but I just have an 'enabled'
attribute in there to switch the thing on and off.

My main problem with configfs (and I've done a few things with it) is
the complexity of the thing, particularly config_group vs config_item vs
config_attribute.  I'd quite like to see just config_group representing
"directory" type objects and attributes representing, well, attributes
in the dir.

That and a bit of wider use would probably see configfs growing helper
macros like those which make sysfs attributes a piece of cake to
implement.

And the trival problem that, ISTR, failing the make_group method always
reports -ENOMEM to userspace, no matter what the actual problem was.  I
think I had a patch around to pass the error code from make_group back
up through to userspace, I wonder what happened to that...

	--Ben.
--
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/