From owner-freebsd-net Sun Aug 12 13:35:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 6AF9A37B407 for ; Sun, 12 Aug 2001 13:35:23 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA98251; Sun, 12 Aug 2001 13:34:33 -0700 (PDT) Message-ID: <3B76E632.28BE644@elischer.org> Date: Sun, 12 Aug 2001 13:25:22 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Jun-ichiro itojun Hagino Cc: net@freebsd.org Subject: Re: IPV6/KAME/protosw integration cleanup References: <20010812201530.DBF2D7BB@starfruit.itojun.org> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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 | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message