On Tue, 6 May 2008, Julian Elischer wrote:
Hi,
Bjoern A. Zeeb wrote:
On Tue, 29 Apr 2008, Julian Elischer wrote:
Hi,
The patch can be found at
http://www.freebsd.org/~julian/mrt.diff
(or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6)
or source can be taken from perforce at:
//depot/user/julian/routing/src
So after looking at the patch a bit more again, could you add wrapper
functions for those like you have done for the old KPI (rtrequest,
rtrequest1,
do you really want to do the extra work instructions?
...
The defines will not give you a stable KPI and having that changed again
if you are going with a prefix for each AF would be a pain if the _fib
versions
are going to change in the future.
hmm fair enough... but let me outline my plans and thoughts
so we can see if you still want this..
[ ... ]
This all however is not ABI compatible so could not go back to 7.x
and I want to check in an initial version that can go back to 7.x
which sort of suggests to me that adding in_xxx functions is
not really required, until I do the next step.
7.x will never get the next step. because the ABI is already set
in stone for 7.x.
I would make the in_xxx stubs in the next step in 8.x.
after the MFC to 7.x of the ABI compat version.
let me know what you think.
Leaving aside any upcoming enhancement if what we have now is
what is going into 7 and possibly 6 we should do the wrapper
functions.
The point is RELENG_7 will live for $(last release + 2 years) so I
guess till 2011 or maybe later. No idea what would happen there in all
that time.
If people start adding support for other AFs we cannot say that the
*_fib variants are not going to change so having the in_* stable
sounds like a good thing for 6 and 7.
Am I missing anything obvious?
I don't mind if they are going to significantly change again in 8
a few weeks later.
/bz
--
Bjoern A. Zeeb Stop bit received. Insert coin for new game.
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
