On Sat, Jun 21, 2008 at 11:03:49AM +1000, Ben Nizette wrote:
quoted text
> 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: joel.becker@oracle.com
Phone: (650) 506-8127
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/