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

to bring this up for debate to see what really are the issues, what

needs to be fixed so we can *properly* use a fs for configuration of

subsystems. I thought configfs was the solution. We currently use and

abuse debugfs, but it doesn't matter -- we don't expect users to

depend on those files for ABI. It, however, it would be nice to

finally export some of these values into a concise place so userspace

*can* rely on them.
I'm ultimately looking for an option to reduce the size of the kernel

you'd need for wirless configuration, or at least to make easier for

userspace. Don't get me wrong I'm not saying I want an alternative to

nl80211 -- I realize we already decided on that and are moving along

in that direction, I'm just wondering once that is done what is the

right place to look at and if we don't have anything what are the

things we need to take into consideration so we *do* use or implement

the *right thing*.
Perhaps a fs is not even the most optimized approach for size anyway

so the benefits may just be helping with the easy design of userspace

applications. Feedback on experiences are welcomed.
PS. I'm hoping those who *really* hate configs can comment
  Luis

--

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.

 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=20

    (echo 0x3 > mntr_flags?) and if we use strings then we cannot easily

    ever rename the flag while keeping ABI/API compatibility.

 3) afaik configfs doesn't actually support the mkdir, ... stuff yet

    that you want for virtual interfaces.
johannes

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

--

Thanks, Ben, for providing constructive comments.  I know I

replied later with some of the known issues.  Here are some tentative

solutions! (Why now, you ask?  I just finished up something and had a
	Ask, and ye shall receive.  I've actually been meaning to look

at this for a while.  Please check out the branch configfs-attr-macros

at my git tree.  Actually, here is the configfs.h with macros, and

configfs_example_macros.c using them.  Let me know if this fits the

bill.
[config-attr-macros:include/linux/configfs.h]

http://oss.oracle.com/git/jlbec/linux-2.6.git/?p=jlbec/linux-2.6.git;a=b...
[config-attr-macros:Documentation/filesystems/configfs/configfs_example_macros.c]

http://oss.oracle.com/git/jlbec/linux-2.6.git/?p=jlbec/linux-2.6.git;a=b...
	Compare and contrast with the original configfs_example.c (now

configfs_example_explicit.c on that branch).  The diff is available

here:
	I've also attacked this one.  The change is in the

make-item-errors branch.  It's already scheduled for linux-next.  Diff

available here:

http://oss.oracle.com/git/jlbec/linux-2.6.git/?p=jlbec/linux-2.6.git;a=c...
Joel
-- 
Life's Little Instruction Book #226
	"When someone hugs you, let them be the first to let go."
Joel Becker

Principal Software Developer

Oracle

E-mail: joel.becker@oracle.com

Phone: (650) 506-8127

--

Looks great, thx :-).  I'll convert some of my stuff over to this
ISTR when I did this I kept the old semantics and used ERR_PTR and

friends if things went pear-shaped.  Given the small number of in-tree

users needing to be moved over, a more intrusive change for the sake of

a cleaner API like you've done is probably a good thing anyway :-)
Thanks again,

	--Ben.
--

Yeah, I like this better than ERR_PTR.

	If you like the macros, I'll try to make the next merge window

as well.  So let me know.
joel
-- 
"I almost ran over an angel

 He had a nice big fat cigar.

 'In a sense,' he said, 'You're alone here

 So if you jump, you'd best jump far.'"
Joel Becker

Principal Software Developer

Oracle

E-mail: joel.becker@oracle.com

Phone: (650) 506-8127

--

I've done a few things recently.  Haavard Skinnemoen has got an

out-of-tree, avr32-specific gpio interface [1] which I first converted

to the generic gpio framework then completely re-wrote.  Both use

configfs but before either version could reach completion they were

obsoleted by David Brownell's gpio sysfs interface.
A version of my gpio-dev interface is attached.  Bear in mind it was

never completed, it's full of known bugs but hey, might be useful for

you anyway :-)
At the moment I'm experimenting with configfs for pinmux control on

AVR32 SoCs.  There's really nothing to see there yet, it's all just
np, will do :-)
[1]

http://git.kernel.org/?p=linux/kernel/git/hskinnemoen/avr32-2.6.git;a=bl...

Looks good.  Fits about what I would expect a configfs interface

to look like, with simple show/store stuff.  I can see where some macros

would have shortened some bolierplate.

	Was there any other boilerplate you found cumbersome?  I mean

outside of defining attribute structs and the show/store_attr()

trampoline functions?  Let me know, so I can incorporate it.
Joel
-- 
Life's Little Instruction Book #444
	"Never underestimate the power of a kind word or deed."
Joel Becker

Principal Software Developer

Oracle

E-mail: joel.becker@oracle.com

Phone: (650) 506-8127

--

You know, I think you've about covered the boilerplate work.  Apart from

that, well it took me a millisecond to work out what the point of

config_{group,item}s was; I went in kinda expecting to see one struct

for directories and one for attributes.  In fact I still not sure I can

explain the need for config_items separate from config_groups.  Little

help?  :-)
--

Groups can create children, items cannot.  Think of kset vs

kobject, which is where it came from.

	Don't worry about directories vs files.  The view from the

client subsystem isn't about filesystem objects.  It's about a hierarchy

of items.  An item is a sigle entity.  It can have attributes.  A group

is an item that can have children.

	The fact that you access it via a filesystem is separate.  We

could have created a system call instead - the callbacks to your client

subsystem would have been the same.  Does that help?
Joel
-- 
Life's Little Instruction Book #511
	"Call your mother."
Joel Becker

Principal Software Developer

Oracle

E-mail: joel.becker@oracle.com

Phone: (650) 506-8127

--

I guess I don't quite see why all items don't have the ability to have

children.  I mean, a config_item has a config_item_type which contains

the group_ops anyway; I don't quite see why the children, default_groups

and subsys members from config_group don't live inside config_item and

be done with it.
In the kobject/kset case the separation makes sense as kobjects are

embedded in things all over the kernel controlling things like ref

counting, device model glue, hotplug info as well as the sysfs

representation.  The config_item doesn't have any responsibilities

outside of the configfs representation (does it?) so the analogy isn't

100%.  Though of course the item/group split makes sense if there are
Indeed, thx.
--

The config_item is indeed embedded in whatever struct it maps

too.  eg, the ocfs2 nodemanager can have a couple hundred nodes, and

that's one config_item per.  The fs/dlm stuff can have even more nodes.
Joel
-- 
Life's Little Instruction Book #222
	"Think twice before burdening a friend with a secret."
Joel Becker

Principal Software Developer

Oracle

E-mail: joel.becker@oracle.com

Phone: (650) 506-8127

--

Righteo, I guess the few 10s of bytes per struct saved by not tracking

children if we know that none can ever exist is the aim here?  Coming

amalgamated in the configfs case but really this whole discussion is

pretty moot. I'm certainly not advocating a re-write of anything in

there!
Thanks for the clarifications (and patience ^_^), I'll do some work

using the new macros and get back to you asap.
Cheers,

--

Sure can do, but it just adds a lot of complexity to the kernel. I don't

see the point, it's not like you need a lot of code to build netlink

messages. Heck, I've done it by _hand_ and used just netlink sockets.
I don't remember the specifics, it's been a while, I guess I could be

thinking of the commitable object support; mostly we'd want to configure

many things in one go, even on a live object. Without disabling that

object first, obviously.
johannes

Ah right.  Netlink is indeed a nice interface for this kind of network

device configuration, I'd probably use that for this task too.
Of course, it isn't a general solution to the problem.  If I were

answering the question in $(SUBJECT) I'd say configfs is a good choice.

In the specific case of network devices, you're lucky enough to have
Yeah, personal preference here.  I come from an embedded background and

have an aversion to tracking more userspace tools than I have to.  This

mainly comes from the fact uClibc (an embedded C library) doesn't

maintain binary compatibility across releases; each time a bugfix comes

out for that my entire userspace needs to be recompiled.  Each userspace

tool I add to my build scripts makes me die a little inside ;-)
	--Ben.
--

On Tue, Jun 10, 2008 at 1:01 AM, Johannes Berg
I actually agree with Johannes here, its not only complexity but also

a burden, not to mention more bloat. We get away with some flag

hackery in ath5k debug.[ch] for example to let you even use the name

of flags but to assume none of this will change over time and to leave

it to us to manage for an actual subsystem seems plainly overkill and
This is of course subjective, I actually think your point about

leaving the complexity of string manipulation and burden on userspace

is perhaps the best argument to avoid a *complete* subsystem interface
OK we could use a fs *only* for retrieval and setting of a few

wireless configuration data then which *is tunable* without *much

complexity*. I'm thinking *standard tunable values* and *standard

stats* like those currently exported via debugfs. This could simply be

optional as well, just as debugfs is. Not even sure if configfs would

be the ideal candidate for this. Alternatively we could just not have

one too, and I'm fine with that too, but we'll just have to make great

userspace tools.
Just wanted to get an idea of what people thought and through their

experience what is best.
  Luis

--

I'd love to hear about the issues as well.  I'd also love to see

what you require, so as to either be able to explain how configfs can do

it for you, or to say that configfs isn't the right fit.  configfs is

designed with a particular goal, and some things don't fit that - and
	You probably expect me to be all "configfs solves world peace,

how can you hate it?"  Nah.  I'd really like to understand your need and

how configfs doesn't fit.  configfs may not fit.  configfs may fit and

I need to explain it better.  Or configfs may not fit but should, and we

then can see how to make it right.
Joel
-- 
"Nothing is wrong with California that a rise in the ocean level

 wouldn't cure."

        - Ross MacDonald
Joel Becker

Principal Software Developer

Oracle

E-mail: joel.becker@oracle.com

Phone: (650) 506-8127

--

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 ...
[ message continues ]