From owner-freebsd-arch Wed Oct 16 3: 3:30 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D06B37B404; Wed, 16 Oct 2002 03:03:27 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2437F43EAA; Wed, 16 Oct 2002 03:03:26 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:501:4819:2000:14e:a4d1:f898:6ed5]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g9GA2mt66864; Wed, 16 Oct 2002 19:02:48 +0900 (JST) Date: Wed, 16 Oct 2002 19:03:33 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Sam Leffler" Cc: "Julian Elischer" , , Subject: Re: CFR: m_tag patch In-Reply-To: <080101c27151$b2e92a30$52557f42@errno.com> References: <18d301c26e5e$8b5c7a30$52557f42@errno.com> <080101c27151$b2e92a30$52557f42@errno.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 59 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >>>>> On Fri, 11 Oct 2002 11:12:02 -0700, >>>>> "Sam Leffler" said: >> > struct m_tag { >> > SLIST_ENTRY(m_tag) m_tag_link; /* List of packet tags > */ >> > u_int16_t m_tag_id; /* Tag ID */ >> > u_int16_t m_tag_len; /* Length of data */ >> > u_int32_t m_tag_cookie; /* Module/ABI */ >> > }; (snip) >> Sorry for interrupting, but please let me make it sure. Do you intend >> to hide the additional member from other modules than the m_tag >> internal? I'm afraid a story that (e.g.) some code fragments in the >> network layer directly refers to m_tag_cookie, which will break source >> level compatibility with other BSDs (when the code fragments are >> shared with others). As suz said before, we (KAME) are very much >> afraid of this kind of story. > The changes I'm proposing for KAME code make no references to m_tag_cookie. > Things should be clear when you have a patch to look at. I know that, but what I'm worrying about is a story that *.c under netinet[6] will have a direct reference to m_tag_cookie *in the future". Then we'll need to separate the code fragments like this: #if defined(__FreeBSD__) && && __FreeBSD__ >= 5 if (mtag->m_tag_cookie != PACKET_TAG_IPSEC_OUT_DONE && mtag->m_tag_cookie != PACKET_TAG_IPSEC_OUT_CRYPTO_NEEDED) continue; #else if (mtag->m_tag_id != PACKET_TAG_IPSEC_OUT_DONE && mtag->m_tag_id != PACKET_TAG_IPSEC_OUT_CRYPTO_NEEDED) continue; #endif (derived from the current KAME's ip6_output.c) We've experienced a lot of headaches due to this type of incompatibility. I fully understand that once some changes are incorporated to a particular BSD, the BSD developers are free to modify the code based on their local policy, even if the result introduces the incompatibility with other BSDs. Of course, there should be a reason for the modification, and the change may provide a better behavior. So, I can only ask, "please understand our position (that needs to handle all *BSDs) and consider a compromise." > I'm working on > getting that to you. Yes, I noticed that, thanks. I'll take a closer look at it later. 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-arch" in the body of the message