lkml.org 
[lkml]   [2007]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] kobject: add kobject_init_ng and kobject_init_and_add functions
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 clean up
> properly. So, if kobject_add() fails, we still need to clean up with
> kobject_put();

You could put that a little less strongly. After kobject_init() you
SHOULD call kobject_put() to clean up properly, and after kobject_add()
you MUST call kobject_del() and kobject_put().

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.

The same sort of rule should apply to other kernel objects, like struct
device. After intialization you have to do a final _put, before that
you just do a kfree(). (And initialization cannot fail.)

> That means we _can_ create a:
> int kobject_init_and_add(struct kobject *kobj, struct ktype *ktype, struct kobject *parent, const char *fmt, ...);
>
> and if that fails, then again, you have to call kobject_put() to clean
> things up, right?

Right. Because you know that the failure must have occurred in the
_add portion.

> Does this look sane?

Yes, I think that will all work correctly.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-11-30 23:13    [W:0.128 / U:0.356 seconds]
©2003-2014 Jasper Spaans. Advertise on this site