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
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
