On Mon, 16 Sep 2019 14:04:00 +0000, Petr Machata wrote: > I was actually thinking about /var/run/netns being mounted elsewhere or > some such, which would prevent "ip netns id" from working. The symbolic > names seem to be accessible from other namespaces just fine --"ip netns > exec foo ip netns exec bar bash" works-- but renaming /var/run breaks > it.
/var/run/netns is a convention introduced by iproute2 and respected by many, but sadly not all, other net management systems. There is no concept of netns names in the kernel. And it is a completely different thing than netnsids. The netns mounts allow you to get a file descriptor referencing the target net name space unambiguously. Such fd can be used for many operations, most importantly to switch yourself into that net name space (see setns(2)). You can obtain the fd by other means, too, for example by opening /proc/<pid>/ns/net. netnsid is a different integer. It is valid only in the net name space it was created in and references a target net name space. It can be used only in netlink operations. It is completely managed by the kernel and does not require the netns to be mounted nor /proc to be mounted. > I don't have other ideas than this. I also think that having an easy to > use way to access the interface outweighs the risks. I think proper documentation might help. Add a warning that this doesn't work across net name spaces and ensure that the API is flexible enough to allow a new field to be added in the future without breaking backwards compatibility if we ever need to start communicating also a netns identifier. Jiri _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
