[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071128173532.00bc72af@gondolin.boeblingen.de.ibm.com>
Date: Wed, 28 Nov 2007 17:35:32 +0100
From: Cornelia Huck <cornelia.huck@...ibm.com>
To: Greg KH <greg@...ah.com>
Cc: linux-kernel@...r.kernel.org, Kay Sievers <kay.sievers@...y.org>,
Alan Stern <stern@...land.harvard.edu>,
Jonathan Corbet <corbet@....net>,
Randy Dunlap <randy.dunlap@...cle.com>
Subject: Re: [RFC] Sample kset/ktype/kobject implementation
On Tue, 27 Nov 2007 15:04:06 -0800,
Greg KH <greg@...ah.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 :)
> 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.
> return NULL;
> }
>
> return foo;
> }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists