>Well what is there now is plainly unacceptable
>I think that it was asked for as a VERY SHORT TERM hack.
>But it has been there a long time...
>I see no reasons so far to not make most of these changes..
well, you are ignoging our design decisions. they are all done
for reasons.
>1/ removal of "control" argument from rip6_input and prepend control mbuf
>to chain AS IT WAS DESIGNED FOR. This makes rip6_input conform to the proto
>type for input. (I have not confirmed that the information in control
>is a valid mbuf but it is an mbuf pointer).
i don't see any "control" argument in rip6_input in kame tree, as well
as freebsd sys/netinet6/raw_ip6.c revision 1.12. which revision
are you looking at?
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet6/raw_ip6.c?rev=1.12&content-type=text/x-cvsweb-markup
if you are talking about rip6_ctlinput(), they are void * from the
start with reason. each of the protocols can define any argument
for xx_ctlinput() from the control input path. therefore, it is okay
for us to define types passed up from icmp6_input() from xx_ctlinput().
>2/ remove all var-args.. This is a disgusting hach that makes it impossible
>for the compiler to catch mismatched functions and arguments.
>NetBSD should know better than this.. they changed it.. they can bear the costs
>of compatibility.. we are NOT going to do that.
>3/ define all prototypes in terms of predefined types to allow
>the compiler to catch wrong assignments quicker (or to change them quicker).
>(this was planned a long time ago but not done for reasons I forget)
i can partially buy this, but for *BSD code sharing, i do need a
compromise here. permit us to use varargs.
>4/ Addition of the "proto" field to output to allow ipprotosw to be completely
>removed. (the special type for that filed need not be done as I only did that
>to ensure that KAME was not using it somewhere to pass something OTHER than
>an proto type.) (other protocols can ignore this field).
no you can't remove "proto" argument from the argument list.
because of the way ipv6 extension header chain (and IPv4 AH/ESP
header) is designed, proto argument has to be passed around, otherwise
we can't know which protocol we are processing (think of raw ip header
processing, like rip_input).
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
