Skip site navigation (1)Skip section navigation (2)
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>