On Fri, Nov 30, 2007 at 06:22:37PM -0500, Alan Stern wrote:
> On Fri, 30 Nov 2007, Greg KH wrote:
> > And you
> > can't know that, so you have to call kobject_put() in order to be safe
> > and clean up everything.
> >
> > Now why did we not do the final kobject_put() in kobject_del() as well?
>
On Fri, 30 Nov 2007, Greg KH wrote:
> > However if kobject_add() is never called, or if it is called and it
> > fails, then it's okay to use kfree(). It's not clear whether this
> > distinction will matter in practice. It's probably best to document
> > this using your stronger description.
On Fri, Nov 30, 2007 at 05:10:33PM -0500, Alan Stern wrote:
> On Fri, 30 Nov 2007, Greg KH wrote:
>
> > Ok, how about this:
> > void kobject_init(struct kobject *kobj, struct ktype *ktype);
> >
> > and then:
> > int kobject_add(struct kobject *kobj, struct kobject *parent, const
> >
On Fri, Nov 30, 2007 at 05:10:33PM -0500, Alan Stern wrote:
> On Fri, 30 Nov 2007, Greg KH wrote:
>
> > Ok, how about this:
> > void kobject_init(struct kobject *kobj, struct ktype *ktype);
> >
> > and then:
> > int kobject_add(struct kobject *kobj, struct kobject *parent, const
> >
On Fri, 30 Nov 2007, Greg KH wrote:
> Ok, how about this:
> void kobject_init(struct kobject *kobj, struct ktype *ktype);
>
> and then:
> int kobject_add(struct kobject *kobj, struct kobject *parent, const
> char *fmt, ...);
>
> After we call kobject_init() we HAVE to call
On Fri, Nov 30, 2007 at 04:19:53PM -0500, Alan Stern wrote:
> On Fri, 30 Nov 2007, Greg KH wrote:
>
> > > My suggestion: Have kobject_init_ng() accept a ktype pointer but not a
> > > parent or name. Instead, make kobject_add_ng() take the parent and
> > > name (possibly a kset also). Then
On Fri, 30 Nov 2007, Greg KH wrote:
> > My suggestion: Have kobject_init_ng() accept a ktype pointer but not a
> > parent or name. Instead, make kobject_add_ng() take the parent and
> > name (possibly a kset also). Then when kobject_init_and_add()
> > encounters an error, it shouldn't do a
On Fri, Nov 30, 2007 at 01:04:20PM -0800, Greg KH wrote:
> > My suggestion: Have kobject_init_ng() accept a ktype pointer but not a
> > parent or name. Instead, make kobject_add_ng() take the parent and
> > name (possibly a kset also). Then when kobject_init_and_add()
> > encounters an error,
On Fri, Nov 30, 2007 at 03:25:52PM -0500, Alan Stern wrote:
> On Fri, 30 Nov 2007, Greg KH wrote:
>
> > +/**
> > + * kobject_init_and_add - initialize a kobject structure and add it to the
> > kobject hierarchy
> > + * @kobj: pointer to the kobject to initialize
> > + * @ktype: pointer to the
On Fri, 30 Nov 2007, Greg KH wrote:
> +/**
> + * kobject_init_and_add - initialize a kobject structure and add it to the
> kobject hierarchy
> + * @kobj: pointer to the kobject to initialize
> + * @ktype: pointer to the ktype for this kobject.
> + * @parent: pointer to the parent of this
This is what the kobject_init function is going to become. Add it to
the kernel and then we can convert over the current kobject_init() users
before renaming it.
Also add a kobject_init_and_add function which bundles up what a lot of
the current callers want to do all at once, and it properly
On Fri, Nov 30, 2007 at 03:25:52PM -0500, Alan Stern wrote:
On Fri, 30 Nov 2007, Greg KH wrote:
+/**
+ * kobject_init_and_add - initialize a kobject structure and add it to the
kobject hierarchy
+ * @kobj: pointer to the kobject to initialize
+ * @ktype: pointer to the ktype for this
On Fri, 30 Nov 2007, Greg KH wrote:
My suggestion: Have kobject_init_ng() accept a ktype pointer but not a
parent or name. Instead, make kobject_add_ng() take the parent and
name (possibly a kset also). Then when kobject_init_and_add()
encounters an error, it shouldn't do a _put() --
On Fri, Nov 30, 2007 at 06:22:37PM -0500, Alan Stern wrote:
On Fri, 30 Nov 2007, Greg KH wrote:
And you
can't know that, so you have to call kobject_put() in order to be safe
and clean up everything.
Now why did we not do the final kobject_put() in kobject_del() as well?
Doing two
On Fri, Nov 30, 2007 at 05:10:33PM -0500, Alan Stern wrote:
On Fri, 30 Nov 2007, Greg KH wrote:
Ok, how about this:
void kobject_init(struct kobject *kobj, struct ktype *ktype);
and then:
int kobject_add(struct kobject *kobj, struct kobject *parent, const
char *fmt, ...);
On Fri, Nov 30, 2007 at 05:10:33PM -0500, Alan Stern wrote:
On Fri, 30 Nov 2007, Greg KH wrote:
Ok, how about this:
void kobject_init(struct kobject *kobj, struct ktype *ktype);
and then:
int kobject_add(struct kobject *kobj, struct kobject *parent, const
char *fmt, ...);
On Fri, 30 Nov 2007, Greg KH wrote:
Ok, how about this:
void kobject_init(struct kobject *kobj, struct ktype *ktype);
and then:
int kobject_add(struct kobject *kobj, struct kobject *parent, const
char *fmt, ...);
After we call kobject_init() we HAVE to call kobject_put() to
On Fri, Nov 30, 2007 at 04:19:53PM -0500, Alan Stern wrote:
On Fri, 30 Nov 2007, Greg KH wrote:
My suggestion: Have kobject_init_ng() accept a ktype pointer but not a
parent or name. Instead, make kobject_add_ng() take the parent and
name (possibly a kset also). Then when
On Fri, Nov 30, 2007 at 01:04:20PM -0800, Greg KH wrote:
My suggestion: Have kobject_init_ng() accept a ktype pointer but not a
parent or name. Instead, make kobject_add_ng() take the parent and
name (possibly a kset also). Then when kobject_init_and_add()
encounters an error, it
On Fri, 30 Nov 2007, Greg KH wrote:
+/**
+ * kobject_init_and_add - initialize a kobject structure and add it to the
kobject hierarchy
+ * @kobj: pointer to the kobject to initialize
+ * @ktype: pointer to the ktype for this kobject.
+ * @parent: pointer to the parent of this kobject.
+ *
This is what the kobject_init function is going to become. Add it to
the kernel and then we can convert over the current kobject_init() users
before renaming it.
Also add a kobject_init_and_add function which bundles up what a lot of
the current callers want to do all at once, and it properly
On Fri, 30 Nov 2007, Greg KH wrote:
However if kobject_add() is never called, or if it is called and it
fails, then it's okay to use kfree(). It's not clear whether this
distinction will matter in practice. It's probably best to document
this using your stronger description.
No,
22 matches
Mail list logo
