Jun-ichiro itojun Hagino wrote:
>
> >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.
no, I just disagree about some of them.
>
> >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?
Sorry, wrong function.. it was output....
here is the fix
@@ -295,16 +295,12 @@
* Tack on options user may have setup with control call.
*/
int
-#if __STDC__
-rip6_output(struct mbuf *m, ...)
-#else
-rip6_output(m, va_alist)
+rip6_output(m, so, sockaddr)
struct mbuf *m;
- va_dcl
-#endif
-{
struct socket *so;
- struct sockaddr_in6 *dstsock;
+ struct sockaddr *sockaddr;
+{
+ struct sockaddr_in6 *dstsock = (struct sockaddr_in6 *)sockaddr;
struct mbuf *control;
struct in6_addr *dst;
struct ip6_hdr *ip6;
@@ -315,14 +311,12 @@
struct ifnet *oifp = NULL;
int type = 0, code = 0; /* for ICMPv6 output statistics only */
int priv = 0;
- va_list ap;
-
- va_start(ap, m);
- so = va_arg(ap, struct socket *);
- dstsock = va_arg(ap, struct sockaddr_in6 *);
- control = va_arg(ap, struct mbuf *);
- va_end(ap);
+ if (m->m_type == MT_CONTROL) {
+ control = m;
+ m = m->m_next;
+ } else
+ control = NULL;
in6p = sotoin6pcb(so);
priv = 0;
@@ -718,7 +712,11 @@
> >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.
>
no.
it can be in the netbsd compatibility code.
it's going away.
> >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).
I din't say remove..
I said ADD.
>
> itojun
--
+------------------------------------+ ______ _ __
| __--_|\ Julian Elischer | \ U \/ / hard at work in
| / \ [EMAIL PROTECTED] +------>x USA \ a very strange
| ( OZ ) \___ ___ | country !
+- X_.---._/ presently in San Francisco \_/ \\
v
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
