All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oren Laadan <orenl@cs.columbia.edu>
To: Dan Smith <danms@us.ibm.com>
Cc: Daniel Lezcano <daniel.lezcano@free.fr>,
	containers@lists.osdl.org,
	Vlad Yasevich <vladislav.yasevich@hp.com>,
	David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org
Subject: Re: [PATCH] [RFC] C/R: inet4 and inet6 unicast routes (v2)
Date: Fri, 30 Apr 2010 22:02:15 -0400	[thread overview]
Message-ID: <4BDB8BA7.1040100@cs.columbia.edu> (raw)
In-Reply-To: <87bpd0zl9l.fsf@caffeine.danplanet.com>



Dan Smith wrote:
> DL> Is it possible to enter the namespace and dump / restore the
> DL> routes with NETLINK_ROUTE from userspace ? Or is it something not
> DL> possible ?
> 
> I'm sure it would be doable.  However, checkpointing the routes that
> way would:
> 
> (a) Be inconsistent with how we checkpoint all the other resources,
>     including the other network resources we handle from the kernel
>     with rtnl
> (b) Require merging of the data from the resources saved in userspace
>     with those saved in kernelspace

See below suggestion for userspace.

> (c) Eliminate the ability for an application to easily checkpoint
>     itself by making a single syscall

I can't think of a use-case of a networked application that takes
a checkpoint of itself (including live network).

Anyway, it's can still be useful to at least do the restore from
userspace (while checkpoint is done in kernel - like with pids).
We may reduce the complexity of restore (in kernel) greatly.

(BTW, instead of syscall one could have a library call that will
take care of the userspace "work").

> (d) Require this same sort of jumping back and forth between
>     namespaces by the userspace task doing the checkpoint/restart
> 

I wonder: if we could relatively simply recreate the network ns,
the interfaces in them, and then restore the routing information
all from userspace before calling sys_restart, it may be useful
in simplifying the kernel code, and allowing more flexibility for
userspace alterations.

I definitely should have asked the question much earlier when you
started the work on restoring network ns and interfaces ... (oh,
I reckon it's better late than never).

Just tossing out the idea, see what kind of thoughts it evokes.
Most likely I'll get a "that won't work because ...", but I'm
hoping for a "hmm.. maybe.. let me see.." :)

Oren.

  parent reply	other threads:[~2010-05-01  2:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-30 17:00 [PATCH] [RFC] C/R: inet4 and inet6 unicast routes (v2) Dan Smith
2010-04-30 18:19 ` Serge E. Hallyn
2010-04-30 18:25   ` Dan Smith
2010-04-30 18:37     ` Serge E. Hallyn
2010-04-30 20:35 ` Daniel Lezcano
2010-04-30 21:24   ` Dan Smith
     [not found]     ` <87bpd0zl9l.fsf-FLMGYpZoEPULwtHQx/6qkW3U47Q5hpJU@public.gmane.org>
2010-05-01  0:26       ` jamal
2010-05-03 14:21         ` Dan Smith
2010-05-03 20:34           ` jamal
2010-05-01  2:02     ` Oren Laadan [this message]
     [not found]   ` <4BDB3F07.2030900-GANU6spQydw@public.gmane.org>
2010-05-01  1:42     ` Oren Laadan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BDB8BA7.1040100@cs.columbia.edu \
    --to=orenl@cs.columbia.edu \
    --cc=containers@lists.osdl.org \
    --cc=daniel.lezcano@free.fr \
    --cc=danms@us.ibm.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=vladislav.yasevich@hp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.