netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hugo Santos <hsantos@av.it.pt>
To: David Miller <davem@davemloft.net>
Cc: kazunori@miyazawa.org, hadi@cyberus.ca, shemminger@osdl.org,
	herbert@gondor.apana.org.au, yoshfuji@linux-ipv6.org,
	netdev@vger.kernel.org, usagi-core@linux-ipv6.org
Subject: Re: Regarding offloading IPv6 addrconf and ndisc
Date: Tue, 1 Aug 2006 12:50:02 +0100	[thread overview]
Message-ID: <20060801115002.GX8334@innerghost.net> (raw)
In-Reply-To: <20060731.142307.35014994.davem@davemloft.net>

[-- Attachment #1: Type: text/plain, Size: 1843 bytes --]

David,

> So all of you userland control-plane fanatics, how will you handle
> things like NFS root with these daemon-required variants of NDISC and
> ARP?

   Do it in the initial ramdisk, we only need the daemon to setup the
 NDISC entries to talk to the NFS server. :-)

   There is obviously a cost associated with this, a deployment cost.
 But there are additional factors we must consider. In a later e-mail
 you state that Linux is a generic purpose operating system; how many
 users need to boot from a NFS root (besides myself :-)? I think that we
 must take into consideration that currently Linux is used in lots of
 distinct environments, not only Desktop computers, and servers, but
 also smaller devices. Configuration/Flexibility vs. optimization is
 something that varies a lot depending on the deployment you are talking
 about, and in most of my scenarios, a small mobile device isn't
 required at the moment to push 100Mbps (optimization) but must be
 capable of verifying it's peers and maintaining secure connections
 (flexibility). So, let's be generic?

   I might have some cycles during the month to code up something in
 this direction, at least for an initial review, i'll try to do so.

   Also, the reliability of a system depends on a lot of things, but
 please, let's not use the assumption that because everything sits in
 the kernel, it will be stable as the number of 'points of failure' is
 smaller; this is only true as long as people work to have stable
 components -- and this is independent of where the components sit. A
 few kernel versions ago (2.6.8 if i remember correctly) i couldn't even
 remove a used network interface safely from the system without hanging
 the network stack. It is possible to have stable user-space code, if
 people developing it work to and make sure it is stable.

   Hugo

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2006-08-01 11:50 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-27 11:25 Regarding offloading IPv6 addrconf and ndisc Hugo Santos
2006-07-27 12:25 ` Kazunori Miyazawa
2006-07-27 17:56   ` Hugo Santos
2006-07-27 23:56   ` Herbert Xu
2006-07-28  1:34     ` David Miller
2006-07-28  1:45       ` Hugo Santos
2006-07-28  2:27         ` David Miller
2006-07-28  3:13           ` Hugo Santos
2006-07-28  3:20             ` David Miller
2006-07-28  3:31               ` Hugo Santos
2006-07-28  4:07                 ` Stephen Hemminger
2006-07-28  8:34                   ` Hugo Santos
2006-07-28 12:45                     ` Jamal Hadi Salim
2006-07-29 13:34                       ` Hugo Santos
2006-07-30  3:28                         ` Kazunori Miyazawa
2006-07-30 11:30                           ` Hugo Santos
2006-07-31 21:23                             ` David Miller
2006-08-01 11:50                               ` Hugo Santos [this message]
2006-08-01 21:54                                 ` David Miller
2006-08-01  0:16                             ` Kazunori Miyazawa
2006-07-28  2:22       ` Herbert Xu
2006-07-28  2:33         ` David Miller
2006-08-01  0:31       ` Andi Kleen
2006-08-01  0:46         ` David Miller
2006-08-01  0:49           ` Roland Dreier
2006-08-01  1:24             ` Jamal Hadi Salim
2006-08-01  1:30               ` Herbert Xu
2006-08-01  1:47                 ` Jamal Hadi Salim
2006-08-01 12:13                   ` Hugo Santos
2006-08-01 12:00           ` Hugo Santos
2006-08-01 21:57             ` David Miller
2006-08-03 13:28               ` Ingo Oeser

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=20060801115002.GX8334@innerghost.net \
    --to=hsantos@av.it.pt \
    --cc=davem@davemloft.net \
    --cc=hadi@cyberus.ca \
    --cc=herbert@gondor.apana.org.au \
    --cc=kazunori@miyazawa.org \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@osdl.org \
    --cc=usagi-core@linux-ipv6.org \
    --cc=yoshfuji@linux-ipv6.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).