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
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
> 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'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
that's fine.
> 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
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: [email protected]
Phone: (650) 506-8127
> 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.
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
(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
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.
On Tue, 2008-06-10 at 10:12 +1000, Ben Nizette wrote:
> 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..)?
netlink.
> > 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?
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.
It's not a lot of code.
> 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.
I personally prefer to put it into userspace.
> > 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.
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
On Tue, Jun 10, 2008 at 1:01 AM, Johannes Berg
<[email protected]> wrote:
> On Tue, 2008-06-10 at 10:12 +1000, Ben Nizette wrote:
>> 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..)?
>
> netlink.
>
>> > 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?
>
> 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.
> It's not a lot of code.
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
abuse.
>> 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.
>
> I personally prefer to put it into userspace.
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
through a configuration file system.
>> > 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.
>
> 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.
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
On Tue, 2008-06-10 at 10:01 +0200, Johannes Berg wrote:
> On Tue, 2008-06-10 at 10:12 +1000, Ben Nizette wrote:
> > 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..)?
>
> netlink.
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
something more specifically tailored to your needs already.
>
> > > 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?
>
> 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.
> It's not a lot of code.
>
> > 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.
>
> I personally prefer to put it into userspace.
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 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: [email protected]
Phone: (650) 506-8127
On Tue, Jun 10, 2008 at 10:12:52AM +1000, Ben Nizette wrote:
>
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
free moment)
> 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.
<snip>
> 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.
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=blob;f=include/linux/configfs.h;h=8be4507ab98f49f43c5212cbafe62178df9a517b;hb=c085c60b185d7431935397e43a868325d8f1da6c
[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=blob;f=Documentation/filesystems/configfs/configfs_example_macros.c;h=c2ece748abdf30a7d67dd9ea25c5e6ac93fbc005;hb=c085c60b185d7431935397e43a868325d8f1da6c
Compare and contrast with the original configfs_example.c (now
configfs_example_explicit.c on that branch). The diff is available
here:
http://oss.oracle.com/git/jlbec/linux-2.6.git/?p=jlbec/linux-2.6.git;a=commitdiff;h=c085c60b185d7431935397e43a868325d8f1da6c
> 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...
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=commitdiff;h=34fbb494fecfd82bcbf9ed698ef305500228a84c
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: [email protected]
Phone: (650) 506-8127
On Wed, 2008-06-18 at 19:48 -0700, Joel Becker wrote:
> 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=blob;f=include/linux/configfs.h;h=8be4507ab98f49f43c5212cbafe62178df9a517b;hb=c085c60b185d7431935397e43a868325d8f1da6c
>
> [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=blob;f=Documentation/filesystems/configfs/configfs_example_macros.c;h=c2ece748abdf30a7d67dd9ea25c5e6ac93fbc005;hb=c085c60b185d7431935397e43a868325d8f1da6c
>
> Compare and contrast with the original configfs_example.c (now
> configfs_example_explicit.c on that branch). The diff is available
> here:
> http://oss.oracle.com/git/jlbec/linux-2.6.git/?p=jlbec/linux-2.6.git;a=commitdiff;h=c085c60b185d7431935397e43a868325d8f1da6c
>
Looks great, thx :-). I'll convert some of my stuff over to this
interface and see how it flies in the real world.
> > 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...
>
> 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=commitdiff;h=34fbb494fecfd82bcbf9ed698ef305500228a84c
>
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.
On Fri, Jun 20, 2008 at 04:19:10PM +1000, Ben Nizette wrote:
> Looks great, thx :-). I'll convert some of my stuff over to this
> interface and see how it flies in the real world.
Excellent. What is your stuff, btw? Got code? Love to see it.
> 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 :-)
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: [email protected]
Phone: (650) 506-8127
On Thu, 2008-06-19 at 23:52 -0700, Joel Becker wrote:
> On Fri, Jun 20, 2008 at 04:19:10PM +1000, Ben Nizette wrote:
> > Looks great, thx :-). I'll convert some of my stuff over to this
> > interface and see how it flies in the real world.
>
> Excellent. What is your stuff, btw? Got code? Love to see it.
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
dicking about atm.
>
> > 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 :-)
>
> 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.
np, will do :-)
--Ben.
>
> joel
>
[1]
http://git.kernel.org/?p=linux/kernel/git/hskinnemoen/avr32-2.6.git;a=blob;f=arch/avr32/mach-at32ap/gpio-dev.c;h=8cf6d1182c31db88fc069a046112a4eaac589308;hb=atmel-2.6.25
On Fri, Jun 20, 2008 at 07:22:56PM +1000, Ben Nizette wrote:
> 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 :-)
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: [email protected]
Phone: (650) 506-8127
On Fri, 2008-06-20 at 14:37 -0700, Joel Becker wrote:
> On Fri, Jun 20, 2008 at 07:22:56PM +1000, Ben Nizette wrote:
> > 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 :-)
>
> 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.
>
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? :-)
--Ben.
> Joel
>
On Sat, Jun 21, 2008 at 11:03:49AM +1000, Ben Nizette wrote:
> 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: [email protected]
Phone: (650) 506-8127
On Fri, 2008-06-20 at 19:02 -0700, Joel Becker wrote:
> On Sat, Jun 21, 2008 at 11:03:49AM +1000, Ben Nizette wrote:
> > 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.
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
grander plans for the config_item in the future.
> 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.
Right
> Does that help?
Indeed, thx.
--Ben.
>
> Joel
>
On Sat, Jun 21, 2008 at 06:03:42PM +1000, Ben Nizette wrote:
> 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
> grander plans for the config_item in the future.
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: [email protected]
Phone: (650) 506-8127
On Sat, 2008-06-21 at 01:44 -0700, Joel Becker wrote:
> On Sat, Jun 21, 2008 at 06:03:42PM +1000, Ben Nizette wrote:
> > 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
> > grander plans for the config_item in the future.
>
> 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.
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
from an embedded background that makes sense to me.
>From a conceptual point of view I still think they would work better
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,
--Ben.
>
> Joel
>