Date: Wed, 15 Aug 2001 11:03:06 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp> To: Julian Elischer <julian@elischer.org> Cc: net@FreeBSD.ORG Subject: Re: IPV6/KAME/protosw integration cleanup Message-ID: <y7v8zgmjd0l.wl@condor.jinmei.org> In-Reply-To: <3B777442.59D83AC4@elischer.org> References: <4246.997609202@itojun.org> <y7v7kw8or55.wl@condor.jinmei.org> <3B777442.59D83AC4@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> On Sun, 12 Aug 2001 23:31:30 -0700, >>>>> Julian Elischer <julian@elischer.org> said: >> I tend to agree with itojun. Although I understand FreeBSD guys want >> to make code from KAME cleaner in terms of FreeBSD's own point of >> view, it will make future merge from KAME to FreeBSD harder. This is >> a trade-off issue, but at this moment, I think we'll still need >> further merge from KAME to FreeBSD, so I'd prefer keeping the code "as >> is" for a while. > Although I understand KAME guys want > to make code from KAME cleaner in terms of KAME's own point of > view, it will make future merge from Almost anywhere else to FreeBSD harder. Yes, of course, you could say that. I guess this is a tradeoff issue. If we change the KAME-based code (which is shared by other *BSDs), port from KAME to FreeBSD would be harder, but other efforts to the code would be easier. If we keep the KAME-based code as is, and if the code has different logic from the FreBSD's latest one, port from KAME to FreeBSD would be easier, but other efforts to the code would be harder. I guess, at this moment, we'll still see more merge efforts to the KAME-based code from the KAME side than from others. (Of course, my view might be wrong, and even if it is the case, I don't think it's a good thing. Changing the KAME-based code according to FreeBSD might cause much more work to the code from others, and we should eventually aim at that goal.) > varargs is not an acceptable solution. please find some other method. > (make a macro start that is defined differently for each platform for example). We'll discuss the best way in the KAME team today. Through this thread, I guess your main concern is about the va_arg hack in the output routines, and we can make compromise on other points, as long as the result is friendly with compiler warnings. If my understanding is wrong, please point it out. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?y7v8zgmjd0l.wl>