On Aug 25, 2014 6:30 AM, "Nicolas Dichtel" <nicolas.dich...@6wind.com> wrote:
>> CRIU wants to save the complete state of a namespace and then restore
>> it. For that to work, any information exposed to things in the
>> namespace *cannot* be globally unique or unique per boot, since CRIU
>> needs to arrange for that information to match whatever it was when
>> CRIU saved it.
>
> How are ifindex of network devices managed? These ifindexes are unique per
> boot,
> thus can change depending on the order in which netdev are created.
> These ifindexes are unique per boot and exposed to userspace ...
>
This does not appear to be true.
$ sudo unshare --net
# ip link add veth0 type veth peer name veth1
# ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
link/ether 06:0d:59:c7:a6:a8 brd ff:ff:ff:ff:ff:ff
3: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
link/ether b2:5c:8b:f2:12:28 brd ff:ff:ff:ff:ff:ff
# logout
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: em1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
state DOWN qlen 1000
>
>>
>> Also, I think that code running in a namespace has no business even
>> knowing a unique identity of that namespace from the perspective of
>> the host.
>
> Another scenario is when you have virtual network devices across two netns.
> You
> need to identify the peer netns to have a netlink message which is fully
> interpretable by the userspace.
Let me try again, with emphasis in the right place.
I think that *code running in a namespace* has no business even
knowing a unique identity of *that namespace* from the perspective of
the host.
In your example, if there's a veth device between netns A and netns B,
then code *in netns A* has no business knowing the identity of its
veth peer if its peer (B) is a sibling or ancestor. It also IMO has
no business knowing the identity of its own netns (A) other than as
"my netns".
If A and B are siblings, then their parent needs to know where that
veth device goes, but I think this is already the case to a sufficient
extent today.
I feel like this discussion is falling into a common trap of new API
discussions. Can one of you who wants this API please articulate,
with a reasonably precise example, what it is that you want to do, why
you can't easily do it already, and how this API helps? I currently
understand how the API creates problems, but I don't understand how it
solves any problems, and I will NAK it (and I suspect that Eric will,
too, which is pretty much fatal) unless that changes.
Thanks,
Andy
>
>
> Regards,
> Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
