Re: [B.A.T.M.A.N.] One step back

[Andrew Lunn <andrew@lunn.ch>]

Hi Marek

> Merging all "big" features at once does not seem feasible. We still
> want to be able to deliver something that does not break each and
> every bit at the same time. I also doubt that David would be happy
> with a big blob to be merged at once.

I guess you need to ask David. Does he prefer one big change, which
breaks compatibility once, but has a high risk of being buggy.  Or
does he prefer breaking compatibility for the next X kernel releases
until all the features are merged?

> For the upcoming routing protocol changes I propose the following:
> First we abstract the routing handling and adjust the current
> routing algo to be usable. Then we add a compile time option to
> choose this algo or the older one (afaik the wireless folks do the
> same with their rate control algorithm). The new algo can be marked
> as experimental and be completed step by step.

Im not sure the wireless folks example is valid. I doubt changing the
rate control algorithm changes the "in the air" protocol. Thus i can
mix experimental and well established algos in a wireless net and it
will all happily work.

I think maybe a better example is TCP flow control algorithms. The TCP
messages stay the same, but how fast start, delayed or repeated ACKs,
enlarging the window etc vary. So TCP-vegas, TCP-reno, TCP-new-reno,
are all compatible with each other and can be mixed on the Internet.

Do you think you can have two routing protocols, side by side, using
the same "in the air" protocol and they are compatible with each
other? David's request is that the "in the air" protocol is fixed.
What is behind the protocol can evolve, but the "in the air" messages
have to remain compatible.

     Andrew