lkml.org 
[lkml]   [2007]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] kobject/kset/ktype documentation and example code updated
On Thu, 20 Dec 2007 13:27:00 -0800 Greg KH wrote:

> On Wed, Dec 19, 2007 at 10:32:06PM -0800, Randy Dunlap wrote:
> > On Wed, 19 Dec 2007 16:30:31 -0800 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.

OK.

> > > Embedding kobjects
> > >
> > > So, for example, the UIO code has a structure that defines the memory
> > > region associated with a uio device:
> > >
> > > struct uio_mem {
> > > struct kobject kobj;
> > > unsigned long addr;
> > > unsigned long size;
> > > int memtype;
> > > void __iomem *internal_addr;
> > > };
> > >
> > > If you have a struct uio_mem structure, finding its embedded kobject is
> > > just a matter of using the kobj structure. Code that works with kobjects
> > > will often have the opposite problem, however: given a struct kobject
> > > pointer, what is the pointer to the containing structure? You must avoid
> > > tricks (such as assuming that the kobject is at the beginning of the
> > > structure) and, instead, use the container_of() macro, found in
> > > <linux/kernel.h>:
> > >
> > > container_of(pointer, type, member)
> > >
> > > where pointer is the pointer to the embedded kobject, type is the type of
> > > the containing structure, and member is the name of the structure field to
> > > which pointer points. The return value from container_of() is a pointer to
> > > the given type. So, for example, a pointer to a struct kobject embedded
> >
> > This is (still) confusing to me. Is it:
> > a pointer "kp" to a ...
> > or is struct uio_mem the "kp"?
>
> How about:
> So, for example, a pointer "kp" to a struct kobject
> embedded within a struct uio_mem could be converted to a
> pointer to the containing uio_mem structure with:

ack.

> > > int kobject_uevent(struct kobject *kobj, enum kobject_action action);
> > >
> > > Use the KOBJ_ADD action for when the kobject is first added to the kernel.
> > > This should be done only after any attributes or children of the kobject
> > > have been initialized properly, as userspace will instantly start to look
> >
> > s/will/may/
>
> No, it's usually a "will", as udev is damm fast these days :)

But that's the point. It assumes that udev is being used. :(


> > > Both types of attributes used here, with a kobject that has been created
> > > with the kobject_create_and_add() can be of type kobj_attribute, no special
> > > custom attribute is needed to be created.
> >
> > ^ multi-run-on sentences....
>
> Is this better:
> Both types of attributes used here, with a kobject that has been
> created with the kobject_create_and_add(), can be of type
> kobj_attribute, so no special custom attribute is needed to be
> created.
>
> If not, any suggestions?

I'm lost in the twisty maze. I suppose that will do until someone
can make it better. ;)


Who is your spell checker?

---
~Randy


\
 
 \ /
  Last update: 2007-12-20 23:11    [W:0.059 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site