[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.0712201741570.29911-100000@netrider.rowland.org>
Date: Thu, 20 Dec 2007 17:57:42 -0500 (EST)
From: Alan Stern <stern@...land.harvard.edu>
To: Greg KH <greg@...ah.com>
cc: Randy Dunlap <randy.dunlap@...cle.com>,
<linux-kernel@...r.kernel.org>, Kay Sievers <kay.sievers@...y.org>,
Jonathan Corbet <corbet@....net>
Subject: Re: [RFC] kobject/kset/ktype documentation and example code updated
On Thu, 20 Dec 2007, Greg KH wrote:
> > > - A ktype is the type of object that embeds a kobject. Every structure
> > > that embeds a kobject needs a corresponding ktype. The ktype controls
> > > what happens when a kobject is no longer referenced and the kobject's
> > > default representation in sysfs.
> >
> > I can't quite parse the last sentence above. Is it:
> >
> > The ktype controls (a) what happens ...
> > and (b) the kobject's default representation in sysfs.
> >
> > ?
>
> How about:
> - A ktype is the type of object that embeds a kobject. Every
> structure that embeds a kobject needs a corresponding ktype.
> The ktype controls what happens to the kobject when it is
> created and destroyed.
I still don't like it. How about being a little more explicit:
A ktype controls certain operations for structures with
embedded kobjects. For example, if struct foo contains an
embedded kobject member then there should be a foo_ktype object
with pointers to the methods for struct foo's. These methods
control what happens when the kobject embedded in a struct foo
is added or destroyed. Every time a new struct foo is created,
&foo_ktype would be passed as the ktype argument in the
kobject_init() call for the structure's embedded kobject.
Each type of structure (not just foo!) with an embedded kobject
needs to have its own corresponding ktype object.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists