From owner-freebsd-net Sun Aug 12 23:34:59 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 0E53837B40F for ; Sun, 12 Aug 2001 23:34:55 -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 XAA00455; Sun, 12 Aug 2001 23:33:44 -0700 (PDT) Message-ID: <3B777284.AA5A1DE8@elischer.org> Date: Sun, 12 Aug 2001 23:24:04 -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: <20010812205433.BE5027BC@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: > > >> >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.... > > ok, > > >here is the fix > > xx_output() has never been governed by protocol switch structure > and therefore ther are numerous variations we see in the tree. > i don't see your problem at all. then why is it in ip6protosw? julian@jules:grep rip6_output */*.c net/if_gif.c: in6_gif_input, rip6_output, 0, rip6_ctloutput, netinet6/in6_proto.c: rip6_input, rip6_output, rip6_ctlinput, rip6_ctloutput, netinet6/in6_proto.c: icmp6_input, rip6_output, rip6_ctlinput, rip6_ctloutput, netinet6/in6_proto.c: encap6_input, rip6_output, 0, rip6_ctloutput, netinet6/in6_proto.c: encap6_input, rip6_output, 0, rip6_ctloutput, netinet6/in6_proto.c: pim6_input, rip6_output, 0, rip6_ctloutput, netinet6/in6_proto.c: rip6_input, rip6_output, 0, rip6_ctloutput, rip_output is also in protosw and I've changed that to pass a sockaddr* instead of a long. if it's in a protosw then it MUST have the same prototype as defined in the protosw. (no "if"s or "but"s) Using varargs to try hide this bug is not an acceptable answer. define ip6protosw's output to have the right definition. then it can be enforced by the compiler. > > >> i can partially buy this, but for *BSD code sharing, i do need a > >> compromise here. permit us to use varargs. > >no. > are you the one who decide the rule here? I think I can round up quite a lot of support here on NOT using varargs for things they were never designed for. The only thing varargs achieve here is the masking and hiding of bugs. I doubt that it is a design goal of KAME to hide bugs. I have seen no good argument for their use. printf's use of varargs in the kernel is shakey enough, but there is support for it in the compiler. > > >it can be in the netbsd compatibility code. > >it's going away. > > more #ifdef = more bug, and kame/freebsd gets left behind. > i really hate all the cosmetic differences *BSD has. freebsd has more > of it than anyone else. NetBSD is the one using varargs in the protosw are they not? > > >I din't say remove.. > >I said ADD. > > so are you proposing to compromise protocol-independent protosw > for the sake of IP? I guess your opinion is too IP centric... I propose to ammend our protosw to add the third argument you require. thus making the two structures the same, and then deleting the ipprotosw. It is needed for any protocol that wants to tunnel over another protocol. it could be generically useful. Certainly IP has always contrilled what is in the networking, but this need not be useful purely for IP. It must solve a class of problems that could also occur with other protocols. Certainly it's preferable to having a different structure for IP vs generic. IPV6 has it's own problems but we'll look at that later as it's still to early. > > itojun > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- +------------------------------------+ ______ _ __ | __--_|\ 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