Re: [RFC] kobject: add kobject_init_ng and kobject_init_and_add functions

[Alan Stern <stern@rowland.harvard.edu>]

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/