[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061115102409.6e6e5dc0@gondolin.boeblingen.de.ibm.com>
Date: Wed, 15 Nov 2006 10:24:09 +0100
From: Cornelia Huck <cornelia.huck@...ibm.com>
To: "Kay Sievers" <kay.sievers@...y.org>
Cc: "Greg KH" <greg@...ah.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
"Andrew Morton" <akpm@...l.org>,
"Martin Schwidefsky" <schwidefsky@...ibm.com>
Subject: Re: [Patch -mm 2/5] driver core: Introduce device_move(): move a
device to a new parent.
On Wed, 15 Nov 2006 09:44:33 +0100,
"Kay Sievers" <kay.sievers@...y.org> wrote:
> Udev and HAL, both will need an event for the moving, with the old
> DEVPATH value in the environment. We want something like a "rename" or
> "move" event. Without that, weird things will happen in userspace,
> because the devpath is used as the key to the device during the whole
> device lifetime. The only weird exception today is the netif rename
> case, which is already handled by special code in udev.
Something like below (completely untested as my test box is currently
inaccessible)? Wouldn't we need something similar for kobject_rename()
as well?
---
include/linux/kobject.h | 1 +
lib/kobject.c | 1 +
2 files changed, 2 insertions(+)
--- linux-2.6-CH.orig/include/linux/kobject.h
+++ linux-2.6-CH/include/linux/kobject.h
@@ -47,6 +47,7 @@ enum kobject_action {
KOBJ_UMOUNT = (__force kobject_action_t) 0x05, /* umount event for block devices (broken) */
KOBJ_OFFLINE = (__force kobject_action_t) 0x06, /* device offline */
KOBJ_ONLINE = (__force kobject_action_t) 0x07, /* device online */
+ KOBJ_MOVE = (__force kobject_action_t) 0x08, /* device move */
};
struct kobject {
--- linux-2.6-CH.orig/lib/kobject.c
+++ linux-2.6-CH/lib/kobject.c
@@ -379,6 +379,7 @@ int kobject_move(struct kobject *kobj, s
old_parent = kobj->parent;
kobj->parent = new_parent;
kobject_put(old_parent);
+ kobject_uevent(kobj, KOBJ_MOVE);
out:
kobject_put(kobj);
return error;
-
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