Serge Hallyn <serge.hallyn@xxxxxxxxxxxxx> writes: > Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): >> Serge Hallyn <serge.hallyn@xxxxxxxxxxxxx> writes: >> >> > Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): >> >> 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 _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
