linux-kernel - Re: [RFC] kobject/kset/ktype documentation and example code updated

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 20 Dec 2007 14:06:59 -0800
From:	Randy Dunlap <randy.dunlap@...cle.com>
To:	Greg KH <greg@...ah.com>
Cc:	linux-kernel@...r.kernel.org, Kay Sievers <kay.sievers@...y.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Jonathan Corbet <corbet@....net>
Subject: Re: [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
--
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/