Hi, On Sat, Jun 02, 2012 at 06:45:47PM +0200, Arne Schwabe wrote: > > returning a macro value, instead of just redefine the > > ROUTE_ORDER_DEFAULT macro for those platforms who need ROUTE_AFTER_TUN > > and use the ROUTE_ORDER_DEFAULT macro directly where needed? > > > > And for type-safety, would it be better to use an typedef enum instead? > I just followed the IFCONFIG_AFTER_TUN/BEFORE_TUN which already is in > place. Just using the defines is fine for me too but it should be > consistend for both options.
I've always wondered why IFCONFIG_AFTER_TUN has been done that way, as
it seemed confusing - it sort of looks like it was done with the option
to change it at run-time later, but I don't really see where this would
make sense. Today all unix platforms have one variant, Windows has the
other one, and reversing order for either isn't going to work...
So I would opt for "no function for ROUTE_ORDER_DEFAULT", and put
cleaning up the IFCONFIG_AFTER_TUN stuff on someones TODO list :-) - but
we could check that one with James...
(JFTR, OpenBSD used to have IFCONFIG_BEFORE_TUN as the single exception
besides Windows - but that looked like "the one who did the port not
understanding how tun(4) works on OpenBSD" - I changed it to
IFCONFIG_AFTER_TUN and that cleaned up quite a bit of special cases
in the code, and it works better than ever before :-) )
What I'm also not really happy in the current implementation of both
options is that all order variants get compiled-in, instead of just
having what the platform in question needs. But that's more intrustive
surgery...
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de
pgp5M1MEoJO5b.pgp
Description: PGP signature
