netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: jamal <hadi-fAAogVwAN2Kw5LPnMra/2Q@public.gmane.org>
To: Dan Smith <danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Cc: containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org,
	Vlad Yasevich <vladislav.yasevich-VXdhtT5mjnY@public.gmane.org>,
	David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] [RFC] C/R: inet4 and inet6 unicast routes (v2)
Date: Fri, 30 Apr 2010 20:26:54 -0400	[thread overview]
Message-ID: <1272673614.14499.10.camel@bigi> (raw)
In-Reply-To: <87bpd0zl9l.fsf-FLMGYpZoEPULwtHQx/6qkW3U47Q5hpJU@public.gmane.org>

On Fri, 2010-04-30 at 14:24 -0700, Dan Smith wrote:

> 
> 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

My 2c:
The problem as i see it (with all net structures not just routes - i was
equally pessimistic when i saw those other net structure
checkpoint/restore changes) is you are faced with a herculean
high-maintainance effort...
You have a separate piece of code which populates structures that _you_
maintain for attributes that are defined elsewhere by other people.
Nobody adding a new attribute that is very important to route
restoration for example is likely to change your code. Unless you tie
the two together (so changing one forces the coder to change the other).
And once people deploy kernels it is hard to change. Historically (for
pragmatic reasons) such rich interfaces sit in user space - much easier
to update user space.
 
cheers,
jamal

  parent reply	other threads:[~2010-05-01  0:26 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 [this message]
2010-05-03 14:21         ` Dan Smith
2010-05-03 20:34           ` jamal
2010-05-01  2:02     ` Oren Laadan
     [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=1272673614.14499.10.camel@bigi \
    --to=hadi-faaogvwan2kw5lpnmra/2q@public.gmane.org \
    --cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
    --cc=danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org \
    --cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
    --cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=vladislav.yasevich-VXdhtT5mjnY@public.gmane.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).