From: Jesper Juhl <jesper.juhl@gmail.com>
To: "linux-os (Dick Johnson)" <linux-os@analogic.com>
Cc: Al Boldi <a1426z@gawab.com>,
netdev@vger.kernel.org, linux-net@vger.kernel.org,
Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] ip / ifconfig redesign
Date: Fri, 2 Dec 2005 23:49:28 +0100 [thread overview]
Message-ID: <9a8748490512021449n3605b952jdc56eca5ffb6ec70@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0512021527090.11277@chaos.analogic.com>
On 12/2/05, linux-os (Dick Johnson) <linux-os@analogic.com> wrote:
>
> On Fri, 2 Dec 2005, Al Boldi wrote:
>
> > The current ip / ifconfig configuration is arcane and inflexible. The reason
> > being, that they are based on design principles inherited from the last
> > century.
> >
> > In a GNU/OpenSource environment, OpenMinds should not inhibit themselves
> > achieving new design-goals to enable a flexible non-redundant configuration.
> >
> > Specifically, '#> ip addr ' exhibits this issue clearly, by requiring to
> > associate the address to a link instead of the other way around.
> >
> > Consider this new approach for better address management:
> > 1. Allow the definition of an address pool
> > 2. Relate links to addresses
> > 3. Implement to make things backward-compatible.
> >
> > The obvious benefit here, would be the transparent ability for apps to bind
> > to addresses, regardless of the link existence.
> >
>
> A link needs to exist for it to have an address.
>
I'm only guessing since I'm not entirely sure what Mr. Boldi means,
but my guess is that he's proposing that an app can bind to an IP
address without that address being assigned to any currently available
interface and then later if that IP does get assigned to an interface
the app will start recieving traffic then. Also possibly allowing the
address to be removed from one interface and then later assigned to
another one without apps noticing.
I don't know /if/ that is what was meant, but that's how I read it.
> > Another benefit includes the ability to scale the link level transparently,
> > regardless of the application bind state.
> >
>
> That doesn't make any sense. Multiple applications can bind to the
> same address. Then can't bind to the same port because they won't
> get all their data.
>
> > And there may be many other benefits... (i.e. 100% OSI compliance)
> >
> What does Open Source Initiative have to do with this at all???
> You are just spewing stuff out.
>
I'm believe Mr. Boldi is refering to OSI as in Open Systems
Interconnection (http://en.wikipedia.org/wiki/OSI_model), not as in
Open Source Initiative.
> > --
> > Al
>
> Also, how does this involve the kernel? The interface to the kernel
> for hardware configuration is via ioctl(). For logic, sockets.
>
> If the user-level tools suck, then they should be fixed. It
> really doesn't have anything to do with the kernel.
>
> Cheers,
> Dick Johnson
>
[snip]
>
> Thank you.
>
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
next prev parent reply other threads:[~2005-12-02 22:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-02 19:53 Al Boldi
2005-12-02 19:59 ` Pekka Savola
2005-12-02 20:08 ` Ben Greear
2005-12-02 20:38 ` linux-os (Dick Johnson)
2005-12-02 22:49 ` Jesper Juhl [this message]
2005-12-10 18:51 ` Stefan Smietanowski
2005-12-02 21:19 ` Jan-Benedict Glaw
2005-12-08 10:15 ` Eric W. Biederman
2005-12-02 22:40 ` Jeff V. Merkey
2005-12-03 13:46 ` Al Boldi
2005-12-11 4:59 ` Bernd Eckenfels
2005-12-14 14:19 ` Al Boldi
[not found] <447BB19E14004A4388CB9A864D2BA7630DF693@hq-ex-6.brocade.com>
2005-12-03 14:58 ` Jan-Benedict Glaw
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=9a8748490512021449n3605b952jdc56eca5ffb6ec70@mail.gmail.com \
--to=jesper.juhl@gmail.com \
--cc=a1426z@gawab.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-net@vger.kernel.org \
--cc=linux-os@analogic.com \
--cc=netdev@vger.kernel.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
all inboxes | Powered by JetHome®