Daniel Lezcano <dlezcano@xxxxxxxxxx> writes: > I agree that will make the life easier for user space developer :) > > I have a few questions about this new behaviour. > > After discussing with Benjamin, this patch means an user can no longer manage a > pool of virtual devices because they will be automatically destroyed when the > namespace exits. I don't think it is a big concern, but just in case I am asking > :) > > Another point, at present, the virtual devices go back to the initial network > namespace when the namespace dies, and this behaviour is used to track the > namespace life cycle. With this patch we have no way to know when the network > namespace has exited. So we can have the last process exiting the network > namespace, but the network namespace can stay alive (eg. some sockets still have > buffer to send) ? Depending on the network interfaces going back to the initial network namespace is problematic in the long term because is breaks recursive containers. I can't see any behavior that does that as anything other than a bug. Especially as I already have production uses for recursive containers. > AFAIR, Pavel told us about a patch extending the "wait" semantic and pass > namespace options to wait for. Is that right Pavel ? Shouldn't we apply this > path before deleting the virtual network devices ? Tell you what. I will post in a bit my patchset that makes /proc/net it's own filesystem, that magically mounts on /proc/self/net. It is a long stupid story why I haven't posted it publicly. At which point we have complete visibility into when a network namespace exits and if we need to be able to wait for it we can just implement a poll method on the root directory. That is simple and will work quite nicely in the long term, and gives us a lot more visibility than a simple this namespace has exited bit. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers