On Thu, 29 Nov 2007 11:55:43 -0500 (EST),
Alan Stern <[EMAIL PROTECTED]> wrote:
> On Thu, 29 Nov 2007, Cornelia Huck wrote:
>
> > > Unfortunately kobjects don't have an owner field. In practice this
> > > means that it isn't possible to pin the owner of some random kobject --
> > > you have to
On Thu, 29 Nov 2007, Cornelia Huck wrote:
> > Unfortunately kobjects don't have an owner field. In practice this
> > means that it isn't possible to pin the owner of some random kobject --
> > you have to know where the kobject came from or what it's embedded in.
> > All users of kobjects nee
On Thu, 29 Nov 2007 10:47:19 -0500 (EST),
Alan Stern <[EMAIL PROTECTED]> wrote:
> On Thu, 29 Nov 2007, Cornelia Huck wrote:
>
> > > The only problem arises when a child's driver retains a reference to
> > > the parent kobject. If things are done properly, this reference should
> > > involve in
On Thu, 29 Nov 2007, Cornelia Huck wrote:
> > The only problem arises when a child's driver retains a reference to
> > the parent kobject. If things are done properly, this reference should
> > involve incrementing the module count -- which would prevent the module
> > from being unloaded in t
On Wed, 28 Nov 2007, Greg KH wrote:
> > > The other kobject fields which should be set, directly or indirectly, by
> > > the creator are its ktype, kset, and parent. We will get to those shortly,
> > > however please note that the ktype and kset must be set before the
> > > kobject_init() function
On Thu, 2007-11-29 at 10:35 +0100, Cornelia Huck wrote:
> On Thu, 29 Nov 2007 08:50:31 +0100,
> Kay Sievers <[EMAIL PROTECTED]> wrote:
>
> > We have ~20 callers of kobject_(un)register(), convert them to
> > kobject_init() + kobject_add() + kobject_uevent(), and just delete the
> > broken kobject_
On Wed, 28 Nov 2007 14:18:18 -0500 (EST),
Alan Stern <[EMAIL PROTECTED]> wrote:
> On Wed, 28 Nov 2007, Cornelia Huck wrote:
>
> > We should perhaps add a bit fat warning here:
> >
> > Note that once you registered your kobject via kobject_add(), you must
> > never use kfree() to free it directly
On Wed, 28 Nov 2007 22:04:58 -0800,
Greg KH <[EMAIL PROTECTED]> wrote:
> > > The uevent function will be called when the uevent is about to be sent to
> > > userspace to allow more environment variables to be added to the uevent.
> >
> > It may be helpful to mention which uevents are by default c
On Thu, 29 Nov 2007 08:50:31 +0100,
Kay Sievers <[EMAIL PROTECTED]> wrote:
> We have ~20 callers of kobject_(un)register(), convert them to
> kobject_init() + kobject_add() + kobject_uevent(), and just delete the
> broken kobject_(un)register() functions from the kobject code.
I find a bit more c
On Wed, 2007-11-28 at 22:08 -0800, Greg KH wrote:
> On Wed, Nov 28, 2007 at 06:00:27PM +0100, Kay Sievers wrote:
> > On Wed, 2007-11-28 at 17:51 +0100, Cornelia Huck wrote:
> > > On Wed, 28 Nov 2007 17:36:29 +0100, Kay Sievers <[EMAIL PROTECTED]> wrote:
> > > > On Wed, 2007-11-28 at 17:12 +0100, Co
On Wed, Nov 28, 2007 at 02:03:28PM -0500, Alan Stern wrote:
> On Tue, 27 Nov 2007, Greg KH wrote:
>
> > Part of the difficulty in understanding the driver model - and the kobject
> > abstraction upon which it is built - is that there is no obvious starting
> > place. Dealing with kobjects requires
On Wed, Nov 28, 2007 at 12:45:45PM +0100, Cornelia Huck wrote:
> On Tue, 27 Nov 2007 15:02:52 -0800,
> Greg KH <[EMAIL PROTECTED]> wrote:
> > - A kset can provide a set of default attributes that all kobjects that
> >belong to it automatically inherit and have created whenever a kobject
> >
On Wed, Nov 28, 2007 at 06:00:27PM +0100, Kay Sievers wrote:
> On Wed, 2007-11-28 at 17:51 +0100, Cornelia Huck wrote:
> > On Wed, 28 Nov 2007 17:36:29 +0100,
> > Kay Sievers <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > On Wed, 2007-11-28 at 17:12 +0100, Cornelia Huck wrote:
> > > > On Wed, 28 Nov
On Wed, Nov 28, 2007 at 01:23:02PM +0100, Kay Sievers wrote:
> On Wed, 2007-11-28 at 12:45 +0100, Cornelia Huck wrote:
> > On Tue, 27 Nov 2007 15:02:52 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
>
> > > A kset serves these functions:
> > >
> > > - It serves as a bag containing a group of objects.
On Wed, Nov 28, 2007 at 10:01:08AM +0100, Cornelia Huck wrote:
> On Tue, 27 Nov 2007 15:02:52 -0800,
> Greg KH <[EMAIL PROTECTED]> wrote:
> > So, for example, UIO code has a structure that defines the memory region
> > associated with a uio device:
> >
> > struct uio_mem {
> > struct kobject k
On Tue, Nov 27, 2007 at 08:50:14PM -0700, Jonathan Corbet wrote:
> Greg KH <[EMAIL PROTECTED]> wrote:
>
> > Jonathan, I used your old lwn.net article about kobjects as the basis
> > for this document, I hope you don't mind
>
> Certainly I have no objections, I'm glad it was useful.
Thanks, it wa
On Wed, 2007-11-28 at 14:36 -0500, Alan Stern wrote:
> On Wed, 28 Nov 2007, Kay Sievers wrote:
>
> > > Actually the current code doesn't seem to check whether kobj->ktype is
> > > NULL or to use the value of kobj->kset->kobj.ktype. Is this an oversight?
> >
> > We just require the ktype.
>
> No
On Wed, 28 Nov 2007, Kay Sievers wrote:
> > Actually the current code doesn't seem to check whether kobj->ktype is
> > NULL or to use the value of kobj->kset->kobj.ktype. Is this an oversight?
>
> We just require the ktype.
No -- we should but we don't. Look at the code for kobject_init() and
On Wed, 2007-11-28 at 14:03 -0500, Alan Stern wrote:
> On Tue, 27 Nov 2007, Greg KH wrote:
>
> > Part of the difficulty in understanding the driver model - and the kobject
> > abstraction upon which it is built - is that there is no obvious starting
> > place. Dealing with kobjects requires unders
On Wed, 28 Nov 2007, Cornelia Huck wrote:
> We should perhaps add a bit fat warning here:
>
> Note that once you registered your kobject via kobject_add(), you must
> never use kfree() to free it directly. The only safe way is to use
Slightly ambiguous. Instead just say:
If you have initialize
On Tue, 27 Nov 2007, Greg KH wrote:
> Part of the difficulty in understanding the driver model - and the kobject
> abstraction upon which it is built - is that there is no obvious starting
> place. Dealing with kobjects requires understanding a few different types,
> all of which make reference to
On Wed, Nov 28, 2007 at 05:09:50PM +0100, Cornelia Huck wrote:
> On Wed, 28 Nov 2007 17:03:07 +0100,
> Kay Sievers <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 2007-11-28 at 16:52 +0100, Cornelia Huck wrote:
> > > On Wed, 28 Nov 2007 13:35:54 +0100,
> > > Kay Sievers <[EMAIL PROTECTED]> wrote:
> > >
On Wed, 2007-11-28 at 17:51 +0100, Cornelia Huck wrote:
> On Wed, 28 Nov 2007 17:36:29 +0100,
> Kay Sievers <[EMAIL PROTECTED]> wrote:
>
> >
> > On Wed, 2007-11-28 at 17:12 +0100, Cornelia Huck wrote:
> > > On Wed, 28 Nov 2007 16:57:48 +0100,
> > > Kay Sievers <[EMAIL PROTECTED]> wrote:
> > >
>
On Wed, 28 Nov 2007 17:36:29 +0100,
Kay Sievers <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2007-11-28 at 17:12 +0100, Cornelia Huck wrote:
> > On Wed, 28 Nov 2007 16:57:48 +0100,
> > Kay Sievers <[EMAIL PROTECTED]> wrote:
> >
> > > On Wed, 2007-11-28 at 16:48 +0100, Cornelia Huck wrote:
> > > > On W
On Wed, 2007-11-28 at 17:12 +0100, Cornelia Huck wrote:
> On Wed, 28 Nov 2007 16:57:48 +0100,
> Kay Sievers <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 2007-11-28 at 16:48 +0100, Cornelia Huck wrote:
> > > On Wed, 28 Nov 2007 13:23:02 +0100,
> > > Kay Sievers <[EMAIL PROTECTED]> wrote:
> > > > On We
On Wed, 28 Nov 2007 16:57:48 +0100,
Kay Sievers <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-11-28 at 16:48 +0100, Cornelia Huck wrote:
> > On Wed, 28 Nov 2007 13:23:02 +0100,
> > Kay Sievers <[EMAIL PROTECTED]> wrote:
> > > On Wed, 2007-11-28 at 12:45 +0100, Cornelia Huck wrote:
> > > > On Tue, 27 N
On Wed, 28 Nov 2007 17:03:07 +0100,
Kay Sievers <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-11-28 at 16:52 +0100, Cornelia Huck wrote:
> > On Wed, 28 Nov 2007 13:35:54 +0100,
> > Kay Sievers <[EMAIL PROTECTED]> wrote:
> >
> > > On Wed, 2007-11-28 at 10:01 +0100, Cornelia Huck wrote:
> > > > On Tue,
On Wed, 2007-11-28 at 16:52 +0100, Cornelia Huck wrote:
> On Wed, 28 Nov 2007 13:35:54 +0100,
> Kay Sievers <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 2007-11-28 at 10:01 +0100, Cornelia Huck wrote:
> > > On Tue, 27 Nov 2007 15:02:52 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
> >
> > > > Among other
On Wed, 2007-11-28 at 16:48 +0100, Cornelia Huck wrote:
> On Wed, 28 Nov 2007 13:23:02 +0100,
> Kay Sievers <[EMAIL PROTECTED]> wrote:
> > On Wed, 2007-11-28 at 12:45 +0100, Cornelia Huck wrote:
> > > On Tue, 27 Nov 2007 15:02:52 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
> > > > The uevent functio
On Wed, 28 Nov 2007 13:35:54 +0100,
Kay Sievers <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-11-28 at 10:01 +0100, Cornelia Huck wrote:
> > On Tue, 27 Nov 2007 15:02:52 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
>
> > > Among other things, kobject_init() sets the kobject's reference count to
> > > on
On Wed, 28 Nov 2007 13:23:02 +0100,
Kay Sievers <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-11-28 at 12:45 +0100, Cornelia Huck wrote:
> > On Tue, 27 Nov 2007 15:02:52 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
>
> > > A kset serves these functions:
> > >
> > > - It serves as a bag containing a gr
On Wed, 2007-11-28 at 10:01 +0100, Cornelia Huck wrote:
> On Tue, 27 Nov 2007 15:02:52 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
> > Among other things, kobject_init() sets the kobject's reference count to
> > one. Calling kobject_init() is not sufficient, however. Kobject users
> > must, at a mi
On Wed, 2007-11-28 at 12:45 +0100, Cornelia Huck wrote:
> On Tue, 27 Nov 2007 15:02:52 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
> > A kset serves these functions:
> >
> > - It serves as a bag containing a group of objects. A kset can be used by
> >the kernel to track "all block devices" or
On Tue, 27 Nov 2007 15:02:52 -0800,
Greg KH <[EMAIL PROTECTED]> wrote:
>
> ksets
>
> A kset is merely a collection of kobjects that want to be associated with
> each other. There is no restriction that they be of the same ktype, but be
> very careful if they are not.
>
> A kset serves these fu
On Tue, 27 Nov 2007 15:02:52 -0800,
Greg KH <[EMAIL PROTECTED]> wrote:
> So, while it is all relativly fresh in my mind, I thought it would be
> good to also document the whole mess, and provide some solid example
> code for others to use in the future.
Cool.
> Embedding kobjects
>
> It is rar
Greg KH <[EMAIL PROTECTED]> wrote:
> Jonathan, I used your old lwn.net article about kobjects as the basis
> for this document, I hope you don't mind
Certainly I have no objections, I'm glad it was useful.
A few little things...
> It is rare (even unknown) for kernel code to create a standalone
On Tue, Nov 27, 2007 at 06:10:42PM -0500, Kyle McMartin wrote:
> On Tue, Nov 27, 2007 at 03:02:52PM -0800, Greg KH wrote:
> > Last updated November 27, 2008
> >
>
> The future is now! ;-)
/me goes off to recharge the flux generator...
Heh, thanks, I'll go fix that.
greg k-h
-
To unsubscribe fr
Greg KH wrote:
> Based on an original article by Jon Corbet for lwn.net written October 1,
> 2003 and located at http://lwn.net/Articles/51437/
>
> Last updated November 27, 2008
^^^
Wow, that's impressive: both kobjects de-mystified and time travel made
possible!
On Tue, Nov 27, 2007 at 03:02:52PM -0800, Greg KH wrote:
> Last updated November 27, 2008
>
The future is now! ;-)
cheers,
Kyle
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kern
Right now I have about 80+ patches reworking the kset/ktype mess in the
-mm tree, cleaning things up and hopefully making it all easier for
people to both use, and understand.
So, while it is all relativly fresh in my mind, I thought it would be
good to also document the whole mess, and provide so
40 matches
Mail list logo
