[lkml]   [2006]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: observations on configfs
On Tue, 2006-08-29 at 09:31 -0700, Joel Becker wrote:

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

Yes, I know this, and I appreciate that sysfs does this generically in
order to get better type checking etc. Maybe it'd be possible to also
give each node a void* data pointer that get's passed around to the
store/show callbacks and hence it doesn't need to do any container_of
conversion but rather cast that data pointer. I'm not really sure, but I
think that the setup required for configfs is a bit too much since one
is essentially implementing what would in sysfs be a subsystem for every
node time.

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

Yes, I know that.

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

Ah, will that new one in pending start out with the same set of
parameters as the one in live? I guess there could be a callback when
something is added to pending so that it can be filled in to look the

Another question. For this application we'll probably need something
/config/cfg80211/wiphy0/eth0/type <- type of interface: sta, monitor,...
/config/cfg80211/wiphy0/eth0/sta/ <- sta attributes, e.g. 'ssid'

but if the type changes, those sta attributes ought to disappear. It
seems that I should be able to do that, but I'm not sure how it would be
done in pending. That is, when in pending I have an object and someone
sets the 'sta' type then the 'sta' attributes directory must show up.

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-30 09:35    [W:0.075 / U:0.904 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site