Re: uevent when moving nic between network namespaces?

[Serge Hallyn <serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>]

Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
> Serge Hallyn <serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> writes:
> 
> > Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
> >> I am not currently working on a patch for this, but I will be happy to
> >> review one. At a quick glance it looks like this could just be as
> >> simple as calling kobject_uevent at the proper time, but testing and
> >> reading through the relevant code paths is probably a good idea as there
> >> always seems to be gotchas in that code.
> >> 
> >> Eric
> >
> > This (the simple fix) works for me, actually.
> >
> > I do notice the ifdef shouldn't be needed, all the better.
> 
> Should we have a KOBJ_ADD in the new network namespace or is the
> KOBJ_MOVE sufficient?

I was wondering about that...  the KOBJ_ADD is technically not sufficient
imo, since a MOVE (for a device which udev/upstart has never seen before)
doesn't necessarily mean "configure this."  So when I pass one end of a
veth into a running ubuntu container, there is no network-interface or
network-interface-security upstart job for it, whereas if I do a
ip link add type veth inside the container, those do get the jobs.

Now, ISTM passing an endpoing into a container is mainly done at
startup, and upstart will end up configuring it anyway.  Nothing is
really breaking in any of the container usages I've seen because of this.
But it would definately be cleaner to pass a KOBJ_ADD before the KOBJ_MOVE.
Otherwise, udev has to guess what the MOVE meant.

If there's no objection, I'll add that (and test it) and send to netdev
on monday.

-serge