Messages in this thread | | | Date | Wed, 28 Nov 2007 22:11:39 -0800 | From | Greg KH <> | Subject | Re: [RFC] Sample kset/ktype/kobject implementation |
| |
On Wed, Nov 28, 2007 at 05:35:32PM +0100, Cornelia Huck wrote: > On Tue, 27 Nov 2007 15:04:06 -0800, > Greg KH <greg@kroah.com> wrote: > > > static struct foo_obj *create_foo_obj(const char *name) > > { > > struct foo_obj *foo; > > int retval; > > > > /* allocate the memory for the whole object */ > > foo = kzalloc(sizeof(*foo), GFP_KERNEL); > > if (!foo) > > return NULL; > > > > /* initialize the kobject portion of the object properly */ > > kobject_set_name(&foo->kobj, "%s", name); > > Returncode not checked :)
good catch. Hm, I don't think anyone checks that function :)
> > foo->kobj.kset = example_kset; > > foo->kobj.ktype = &foo_ktype; > > > > /* > > * Register the kobject with the kernel, all the default files will > > * be created here and the uevent will be sent out. If we were to > > * call kobject_init() and then kobject_add() we would be > > * responsible for sending out the initial KOBJ_ADD uevent. > > */ > > retval = kobject_register(&foo->kobj); > > if (retval) { > > kfree(foo); > > kobject_put(foo) is needed since it gets you through kobject_cleanup() > where the name can be freed.
No, kobject_register() should have handled that for us, right?
thanks,
greg k-h - 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/
| |