From: Andrew Lunn <andrew@lunn.ch>
To: The list for a Better Approach To Mobile Ad-hoc Networking
<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] switch routing algorithm at runtime
Date: Tue, 6 Dec 2011 16:21:06 +0100 [thread overview]
Message-ID: <20111206152106.GJ10131@lunn.ch> (raw)
In-Reply-To: <20111206150134.GA12168@pandem0nium>
On Tue, Dec 06, 2011 at 04:01:34PM +0100, Simon Wunderlich wrote:
> Hey there,
>
> On Mon, Dec 05, 2011 at 03:25:53PM +0100, Andrew Lunn wrote:
> > > Here comes the chicken & egg problem: We can't have bat0 and its routing
> > > algorithm selection before we did not add at least one hard-interface.
>
> an alternative we may consider:
>
> We could just write the name of the algorithm in a debugfs file called
> "routing_algorithm". It is filled with batmanIV as the default algorithm
> to start with, and whatever is written there is used for the next soft interface
> to be created.
>
> This would be backward compatible and changes are only made upon creation of a
> soft interface. It would also allow different soft interfaces using different
> routing algorithms (if someone really needs it). Putting it into debugfs may be
> not the worst idea, as changing routing algorithms is (currently) only done for
> debugging purposes anyway.
Hi Simon
When it is in debugfs, it implies that the user has no choice, it is a
debug tool only. So when the development is finished, one day batman
will just swap from IV to V, and the user gets no choice?
For the moment, i think it is O.K. in debugfs. However, there should
be some sort of idea how this is going to work when it comes to
actually mainstream use of V. Is it simply that IV is dead, you need
to use V now. Or do we give the user a choice and some file under /sys
to make this choice?
Also, i would suggest not adding batctl support for this file in
/debugfs, since then routing_algorithm is on the first steps towards
becoming part of the ABI, even thought it is in debugfs and should not
be part of an ABI.
Andrew
next prev parent reply other threads:[~2011-12-06 15:21 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-05 9:56 [B.A.T.M.A.N.] switch routing algorithm at runtime Marek Lindner
2011-12-05 9:56 ` [B.A.T.M.A.N.] [PATCH 1/3] batman-adv: add infrastructure to change " Marek Lindner
2011-12-05 9:56 ` [B.A.T.M.A.N.] [PATCH 2/3] batman-adv: convert batman iv algorithm to use dynamic infrastructure Marek Lindner
2011-12-05 9:56 ` [B.A.T.M.A.N.] [PATCH 3/3] batman-adv: allowing changing the routing algorithm via sysfs Marek Lindner
2011-12-05 11:27 ` [B.A.T.M.A.N.] switch routing algorithm at runtime Andrew Lunn
2011-12-05 11:35 ` Marek Lindner
2011-12-05 12:13 ` Andrew Lunn
2011-12-05 13:38 ` Marek Lindner
2011-12-05 14:09 ` Antonio Quartulli
2011-12-05 14:38 ` Andrew Lunn
2011-12-05 14:44 ` Antonio Quartulli
2011-12-05 14:25 ` Andrew Lunn
2011-12-06 15:01 ` Simon Wunderlich
2011-12-06 15:06 ` Antonio Quartulli
2011-12-06 15:21 ` Andrew Lunn [this message]
2011-12-06 15:30 ` Marek Lindner
2011-12-06 17:36 ` Simon Wunderlich
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=20111206152106.GJ10131@lunn.ch \
--to=andrew@lunn.ch \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox