Date: Wed, 16 Oct 2002 07:46:10 -0700 From: Luigi Rizzo <rizzo@icir.org> To: "JINMEI Tatuya / ?$B?@L@C#:H?(B" <jinmei@isl.rdc.toshiba.co.jp> Cc: Sam Leffler <sam@errno.com>, Julian Elischer <julian@elischer.org>, freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch Message-ID: <20021016074610.C34626@carp.icir.org> In-Reply-To: <y7vbs5u4s5m.wl@ocean.jinmei.org>; from jinmei@isl.rdc.toshiba.co.jp on Wed, Oct 16, 2002 at 07:03:33PM %2B0900 References: <Pine.BSF.4.21.0210071613260.34884-100000@InterJet.elischer.org> <18d301c26e5e$8b5c7a30$52557f42@errno.com> <y7vd6qhg0vj.wl@ocean.jinmei.org> <080101c27151$b2e92a30$52557f42@errno.com> <y7vbs5u4s5m.wl@ocean.jinmei.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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" <sam@errno.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021016074610.C34626>