[PATCH] [RFC] C/R: inet4 and inet6 unicast routes (v2)
orenl at cs.columbia.edu
Fri Apr 30 18:42:58 PDT 2010
Daniel Lezcano wrote:
> Dan Smith wrote:
>> This patch adds support for checkpointing and restoring route information.
>> It keeps enough information to restore basic routes at the level of detail
>> of /proc/net/route. It uses RTNETLINK to extract the information during
>> checkpoint and also to insert it back during restore. This gives us a
>> nice layer of isolation between us and the various "fib" implementations.
>> Changes in v2:
>> This version of the patch actually moves the current task into the
>> desired network namespace temporarily, for the purposes of examining and
>> restoring the route information. This is a instead of creating a cross-
>> namespace socket to do the job, as was done in v1.
>> This is just an RFC to see if this is an acceptable method. For a final
>> version, adding a helper to nsproxy.c would allow us to create a new
>> nsproxy with the desired netns instead of creating one with
>> copy_namespaces() just to kill it off and use the target one.
>> I still think the previous method is cleaner, but this way may violate
>> fewer namespace boundaries (I'm still undecided :)
>> Signed-off-by: Dan Smith <danms at us.ibm.com>
>> Cc: David Miller <davem at davemloft.net>
>> Cc: Vlad Yasevich <vladislav.yasevich at hp.com>
>> Cc: jamal <hadi at cyberus.ca>
> Hi Dan,
> Eric did a patchset (as Jamal mentioned it) where you can have a process
> to enter a specific namespace from userspace.
> Is it possible to enter the namespace and dump / restore the routes with
> NETLINK_ROUTE from userspace ? Or is it something not possible ?
I also think that restoring routes from userspace, if feasible,
will be advantageous.
Besides, that will simplify cases in which userspace would like to
restore something different (in terms of routes) than what was
saved in the checkpoint.
So the question is, what would it take ?
More information about the Containers