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" <[EMAIL PROTECTED]> 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.
> [EMAIL PROTECTED]
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
