Date: Wed, 16 Oct 2002 19:03:33 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp> To: "Sam Leffler" <sam@errno.com> Cc: "Julian Elischer" <julian@elischer.org>, <freebsd-arch@FreeBSD.ORG>, <freebsd-net@FreeBSD.ORG> Subject: Re: CFR: m_tag patch Message-ID: <y7vbs5u4s5m.wl@ocean.jinmei.org> In-Reply-To: <080101c27151$b2e92a30$52557f42@errno.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> On Fri, 11 Oct 2002 11:12:02 -0700,
>>>>> "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-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?y7vbs5u4s5m.wl>