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
same.
Another question. For this application we'll probably need something
like
/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.
Thanks,
johannes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
