From owner-freebsd-arch Wed Oct 16 7:46:17 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 88ECB37B401; Wed, 16 Oct 2002 07:46:15 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F26543E8A; Wed, 16 Oct 2002 07:46:15 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9GEkBpJ034883; Wed, 16 Oct 2002 07:46:11 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g9GEkAG2034882; Wed, 16 Oct 2002 07:46:10 -0700 (PDT) (envelope-from rizzo) Date: Wed, 16 Oct 2002 07:46:10 -0700 From: Luigi Rizzo To: "JINMEI Tatuya / ?$B?@L@C#:H?(B" Cc: Sam Leffler , Julian Elischer , freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch Message-ID: <20021016074610.C34626@carp.icir.org> References: <18d301c26e5e$8b5c7a30$52557f42@errno.com> <080101c27151$b2e92a30$52557f42@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jinmei@isl.rdc.toshiba.co.jp on Wed, Oct 16, 2002 at 07:03:33PM +0900 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 Actually from what i have read on previous postings on this thread, the only additional check that you might/will need is to make sure that m_tag_cookie corresponds to the GENERIC ABI. Also note that in your example the code should be conditional on __FreeBSD_version and not on __FreeBSD__ cheers luigi On Wed, Oct 16, 2002 at 07:03:33PM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote: ... > >>>>> "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-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message