[lkml]   [2006]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: observations on configfs
On Tue, Aug 29, 2006 at 06:14:30PM +0200, Johannes Berg wrote:
> I recently tried to use configfs for configuring (virtual) network
> interfaces on top of cfg80211. Here's what I noticed then and in later
> thoughts about it.

Thanks! I always appreciate thoughts and comments.

> (1) it is possible to have
> | $ ls /config
> | 02-example 02-example
> Seems like that should be prohibited when registering the new
> configfs subsystem.

Hmm, yeah, this is a bug. I've added Thanks for
reporting this!

> (2) why is are there no show/store in struct configfs_attribute? That
> leads to complications like this (straight from ocfs2):
> struct o2nm_node_attribute {
> struct configfs_attribute attr;
> ssize_t (*show)(struct o2nm_node *, char *);
> ssize_t (*store)(struct o2nm_node *, const char *, size_t);
> };
> static struct o2nm_node_attribute o2nm_node_attr_num = {
> .attr = { .ca_owner = THIS_MODULE,
> .ca_name = "num",
> .ca_mode = S_IRUGO | S_IWUSR },
> .show = o2nm_node_num_read,
> .store = o2nm_node_num_write,
> };
> ...
> I suppose I could ask the same of sysfs, but there it actually seems to
> make sense because it only needs to be implemented once per subsystem.
> The same is true of configfs, however for configfs one usually has to
> implement a new subsystem to get useful functionality...

I did get this straight from sysfs. You are right, there is
less sharing of such things in configfs compared to sysfs. Here's the
thing: this scheme allows the generic code (the ->show() and ->store()
methods) to take struct configfs_attribute, but the actual worker
functions take context appropriate objects, such a struct o2nm_node in
the example you placed. Without this indirection, every ->show() would
have to do its own conversion from configfs_attribute to the context
appropriate structures.

> (3) just thought about the pending/live thing a bit more. For one I
> notice that it is not implemented, which is sad because I could really
> use it well here. Secondly, and more importantly, I think the concept is
> slightly flawed.

Yeah, I'm sorry I haven't gotten to it yet.

> If I have virtual devices represented in configfs, they are all
> net_devices at their core, of course. Assuming they are below
> /config/cfg80211/wiphy0/, say eth0 is created as pending/eth0. Then, you
> move it to live/eth0 at which point the netdevice is allocated and
> registered (if it fails due to name collision you need to chose another
> name by renaming it in pending).

Also note that you can fail the callback in your driver,
preventing the rename(2) -- eg, if a particular option needs to be set
but isn't, etc.

> This is all great, but say then I want to change a few parameters of the
> interface. So I move it to pending again. At this point, we run into
> problems. We can either (a) remove the net_device or (b) keep it live.

The plan is (c). Build a new one in pending, and rename(2) it
on top of the current one.

> Hence, I think it should be slightly redesigned to allow for another
> case, namely hardlinking the directory from live into pending (make sure
> name stays the same) at which point it isn't removed. Then, moving it
> from live to pending would be taken as an indication to actually remove
> the net_device associated with it, and linking it just as a
> reconfiguration request.

Linux doesn't support directory hardlinks, for good reason.



Life's Little Instruction Book #313

"Never underestimate the power of love."

Joel Becker
Principal Software Developer
Phone: (650) 506-8127
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-08-29 18:35    [W:0.089 / U:0.972 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site