2008-11-24 10:50:53

by Daniel Lezcano

[permalink] [raw]
Subject: [patch 1/1][RFC]Handle uevent per namespace



Attachments:
make-kobject-uevent-per-namespace.patch (5.13 kB)

2008-11-24 15:15:13

by Kay Sievers

[permalink] [raw]
Subject: Re: [patch 1/1][RFC]Handle uevent per namespace

On Mon, Nov 24, 2008 at 11:50, Daniel Lezcano <[email protected]> wrote:

struct kobject {
const char *name;
struct list_head entry;
@@ -63,6 +65,9 @@ struct kobject {
struct kset *kset;
struct kobj_type *ktype;
struct sysfs_dirent *sd;
+#ifdef CONFIG_NET
+ struct net *net;
+#endif
struct kref kref;
unsigned int state_initialized:1;
unsigned int state_in_sysfs:1;

We cannot do that. Network specific stuff does not belong into
kobjects. Kobjects are not in any way subsystem specific, and we need
to keep it that way.

Thanks,
Kay

2008-11-24 15:21:45

by Daniel Lezcano

[permalink] [raw]
Subject: Re: [patch 1/1][RFC]Handle uevent per namespace

Kay Sievers wrote:
> On Mon, Nov 24, 2008 at 11:50, Daniel Lezcano <[email protected]> wrote:
>
> struct kobject {
> const char *name;
> struct list_head entry;
> @@ -63,6 +65,9 @@ struct kobject {
> struct kset *kset;
> struct kobj_type *ktype;
> struct sysfs_dirent *sd;
> +#ifdef CONFIG_NET
> + struct net *net;
> +#endif
> struct kref kref;
> unsigned int state_initialized:1;
> unsigned int state_in_sysfs:1;
>
> We cannot do that. Network specific stuff does not belong into
> kobjects. Kobjects are not in any way subsystem specific, and we need
> to keep it that way.

That makes sense :)

Is there a way to follow up from the kobject, the netdev associated with
it ? I mean in the function kobject_uevent_env, how can I check the
event is related to a network device and retrieve the struct net_device
from it ?

Thanks.
-- Daniel

2008-11-24 15:42:37

by Greg KH

[permalink] [raw]
Subject: Re: [patch 1/1][RFC]Handle uevent per namespace

On Mon, Nov 24, 2008 at 11:50:34AM +0100, Daniel Lezcano wrote:
>

> Subject: Handle uevent per namespace
> From: Daniel Lezcano <[email protected]>
>
> At present when a network device is destroyed, inside a network
> namespace, and this device has the same name as one network device
> belonging to the initial network namespace (eg. eth0), the udev daemon
> will disable the interface in the initial network namespace.
>
> IMHO, udev should not receive this event. The uevents should be per
> namespace or at least do not send events when not for the initial
> network namespace.

IMHO, network namespaces are a mess and not something that you should be
doing at all :)

> The following patch is a RFC for making uevent namespace aware. I don't
> know this part of the kernel code, so I am pretty sure t is not the
> right way to do that :)

Like Kay said, please don't change the kobject core for this, try just
filtering in the network core the events that you handle there.

good luck,

greg k-h

2008-11-24 15:55:33

by Daniel Lezcano

[permalink] [raw]
Subject: Re: [patch 1/1][RFC]Handle uevent per namespace

Greg KH wrote:
> On Mon, Nov 24, 2008 at 11:50:34AM +0100, Daniel Lezcano wrote:
>
>> Subject: Handle uevent per namespace
>> From: Daniel Lezcano <[email protected]>
>>
>> At present when a network device is destroyed, inside a network
>> namespace, and this device has the same name as one network device
>> belonging to the initial network namespace (eg. eth0), the udev daemon
>> will disable the interface in the initial network namespace.
>>
>> IMHO, udev should not receive this event. The uevents should be per
>> namespace or at least do not send events when not for the initial
>> network namespace.
>
> IMHO, network namespaces are a mess and not something that you should be
> doing at all :)
>
>> The following patch is a RFC for making uevent namespace aware. I don't
>> know this part of the kernel code, so I am pretty sure t is not the
>> right way to do that :)
>
> Like Kay said, please don't change the kobject core for this, try just
> filtering in the network core the events that you handle there.

Oh, why I didn't think about that :)
That will be a cleaner and a smaller patch.

Thanks.
-- Daniel