All of lore.kernel.org
 help / color / mirror / Atom feed
From: Henning Rogge <hrogge@googlemail.com>
To: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [B.A.T.M.A.N.] Staging: batman-adv for 2.6.36 (3)
Date: Sat, 10 Jul 2010 10:54:41 +0200	[thread overview]
Message-ID: <201007101055.11401.hrogge@googlemail.com> (raw)
In-Reply-To: <201007101040.53995.sven.eckelmann@gmx.de>

[-- Attachment #1: Type: Text/Plain, Size: 1297 bytes --]

Am Samstag 10 Juli 2010, 10:40:52 schrieb Sven Eckelmann:
> Daniel Seither wrote:
> > Am 10.07.2010 01:07, Sven Eckelmann wrote:
> > > batman-adv works quite well for us - but that doesn't mean that it is
> > > good in context of the current kernel development. And who should know
> > > it better than the netdev guys.
> > 
> > Hagen Paul Pfeifer suggested in his message "a generalized architecture
> > and a user space implementation of the protocol". What came to my mind
> > when I read this again was a division of control plane and
> > data/forwarding plane as known from traditional routing.
> > 
> > The whole forwarding stuff would stay in the kernel, using a simple
> > routing table (for destination X, send to node Y on interface Z).
> 
> This would go against the bonding/alternating functionality.
The bonding/alternating functionality could be part of the routing framework. 
I think there is something similar on IP layer routing in linux.

(a framework like this would make it very easy to port additional routing 
daemons for layer 2 routing, I already hear the 802.11s group crying because 
of competitors ;) ).

Henning Rogge

-- 
1) You can't win.
2) You can't break even.
3) You can't leave the game.
— The Laws of Thermodynamics, summarized

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2010-07-10  8:54 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-25 22:28 [B.A.T.M.A.N.] Staging: batman-adv for 2.6.36 (2) Sven Eckelmann
2010-06-25 22:28 ` [B.A.T.M.A.N.] [PATCH 1/8] Staging: batman-adv: Convert names from Java to C style Sven Eckelmann
2010-06-25 22:28 ` [B.A.T.M.A.N.] [PATCH 2/8] Staging: batman-adv: Avoid rounding issues for local hna timeout Sven Eckelmann
2010-06-25 22:28 ` [B.A.T.M.A.N.] [PATCH 3/8] Staging: batman-adv: Lower resolution for timeouts Sven Eckelmann
2010-06-25 22:28 ` [B.A.T.M.A.N.] [PATCH 4/8] Staging: batman-adv: replace manual calculation by msecs_to_jiffies() for better readability Sven Eckelmann
2010-06-25 22:28 ` [B.A.T.M.A.N.] [PATCH 5/8] Staging: batman-adv: Add sysfs abi documentation about bonding Sven Eckelmann
2010-06-25 22:28 ` [B.A.T.M.A.N.] [PATCH 6/8] Staging: batman-adv: adapting source version to revised versioning scheme Sven Eckelmann
2010-06-25 22:28 ` [B.A.T.M.A.N.] [PATCH 7/8] Staging: batman-adv: Add include guards to all header files Sven Eckelmann
2010-06-25 22:28 ` [B.A.T.M.A.N.] [PATCH 8/8] Staging: batman-adv: fix early debugfs deinitialization Sven Eckelmann
2010-06-26  0:36 ` [B.A.T.M.A.N.] Staging: batman-adv for 2.6.36 (3) Sven Eckelmann
2010-06-26  0:36   ` [B.A.T.M.A.N.] [PATCH 1/2] Staging: batman-adv: Allow to build it inside the kernel Sven Eckelmann
2010-06-26  0:36   ` [B.A.T.M.A.N.] [PATCH 2/2] Staging: batman-adv: Remove dependency to PROCFS Sven Eckelmann
2010-07-06 13:04 ` [B.A.T.M.A.N.] Staging: batman-adv for 2.6.36 (3) Sven Eckelmann
2010-07-06 15:20   ` Greg KH
2010-07-06 15:36     ` Sven Eckelmann
2010-07-06 16:17       ` Greg KH
2010-07-09 23:07         ` Sven Eckelmann
2010-07-09 23:40           ` Greg KH
2010-07-10  0:42           ` Daniel Seither
2010-07-10  8:40             ` Sven Eckelmann
2010-07-10  8:54               ` Henning Rogge [this message]
2010-07-10  9:09                 ` Sven Eckelmann
2010-07-10  9:59               ` Daniel Seither

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=201007101055.11401.hrogge@googlemail.com \
    --to=hrogge@googlemail.com \
    --cc=b.a.t.m.a.n@lists.open-mesh.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 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.