Re: uevent when moving nic between network namespaces?

[ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)]

Serge Hallyn <serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> writes:

> 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.

Sounds good.  Right now I have the suspicion we might want our own
variant on sysfs_move that sends these instead of the move...

But let's confirm things work better with add/remove before we go crazy
on the best way to generate maintainable code.


Eric