From: Dan Smith <danms@us•ibm.com>
To: hadi@cyberus•ca
Cc: Daniel Lezcano <daniel.lezcano@free•fr>,
containers@lists•osdl.org,
Vlad Yasevich <vladislav.yasevich@hp•com>,
netdev@vger•kernel.org, David Miller <davem@davemloft•net>
Subject: Re: [PATCH] [RFC] C/R: inet4 and inet6 unicast routes (v2)
Date: Mon, 03 May 2010 07:21:02 -0700 [thread overview]
Message-ID: <87y6g1xe0h.fsf@caffeine.danplanet.com> (raw)
In-Reply-To: <1272673614.14499.10.camel@bigi> (jamal's message of "Fri\, 30 Apr 2010 20\:26\:54 -0400")
j> The problem as i see it (with all net structures not just routes -
j> i was equally pessimistic when i saw those other net structure
j> checkpoint/restore changes) is you are faced with a herculean
j> high-maintainance effort... You have a separate piece of code
j> which populates structures that _you_ maintain for attributes that
j> are defined elsewhere by other people. Nobody adding a new
j> attribute that is very important to route restoration for example
j> is likely to change your code. Unless you tie the two together (so
j> changing one forces the coder to change the other). And once
j> people deploy kernels it is hard to change. Historically (for
j> pragmatic reasons) such rich interfaces sit in user space - much
j> easier to update user space.
The benefits of doing what we can in userspace are well-understood and
arguing for doing so where it makes sense is, of course, a good idea.
However, it seems to me that the rtnl interface provides us a
reasonable layer of isolation between us and such changes. Am I
wrong? The rtnl messages appear to be rather generic and timeless,
and in most cases have a significant amount of flexibility with
respect to allowing advanced attributes to be ignored (which implies
taking the default).
In many other areas of C/R we're not so lucky and don't have a
well-defined interface for dumping that information out of the
kernel...
--
Dan Smith
IBM Linux Technology Center
email: danms@us•ibm.com
next prev parent reply other threads:[~2010-05-03 14:21 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 [this message]
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=87y6g1xe0h.fsf@caffeine.danplanet.com \
--to=danms@us$(echo .)ibm.com \
--cc=containers@lists$(echo .)osdl.org \
--cc=daniel.lezcano@free$(echo .)fr \
--cc=davem@davemloft$(echo .)net \
--cc=hadi@cyberus$(echo .)ca \
--cc=netdev@vger$(echo .)kernel.org \
--cc=vladislav.yasevich@hp$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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