> i am pretty sure that this change does not affect low level drivers;
> the "any software that uses them" comment almost surely refers to the
> m_aux field, not to the entire struct mbuf.
>
> This said, fair behaviour cannot be requested to one side only.
>
> Sam posted patches, so those who have the hw/sw for which they
> suspect incompatibilities have all the resources to try the new
> code and find out whether their suspicions are founded or not.
> I am surely willing to listen to objections based on convincing
> evidence of breakage, whereas pure speculation is a much weaker
> argument.
>

John and I have been talking and there was some confusion on what might
break.  To try to clarify again: this should only affect existing software
if it:

1. Calls ip_output directly.
2. Uses aux mbufs; e.g. calls m_aux*.

Network interface drivers should never do #1.  If they do #2 then I'd be
very surprised, but that's what I'm searching for.  John sent me an nm of
the ET driver and it does not appear to do either.  I understand that folks
in this situation may have trouble verifying whether or not this patch would
break their binary drivers as they may not be running a version of the
system where this patch would apply cleanly.

Regardless, I'm waiting a week to hear from everyone and then I'll decide if
it's safe to commit the mods or not.

    Sam

>
> On Fri, Nov 22, 2002 at 08:45:20AM -0800, John Polstra wrote:
> > In article <196301c291e9$56d25e70$[EMAIL PROTECTED]>, Sam Leffler
> > <[EMAIL PROTECTED]> wrote:
> > > I want to commit the mbuf packet tag changes to stable.  These
> > > changes replace the aux mbuf pointer in the mbuf with a list of
> > > "packet tags".  This does not change the size of the mbuf structure
> > > but does affect any software that uses them (presently only KAME
> > > ipsec which has been patched to use packet tags instead).
> >
> > I would strongly prefer that you not put this into the 4.x branch.
> > The project has a policy against incompatible ABI changes within the
> > -stable branch.  If you do this MFC then those of us who rely on
> > third-party binary-only network drivers (such as the ET Inc. drivers,
> > upon which I and many others rely for network connectivity) will be
> > SOL.  Changing the ABI within the branch is unfair to the vendors who
> > try to maintain drivers for FreeBSD, and it only discourages them from
> > trying to support our operating system.  Let's just let the 4.x branch
> > live out the rest of its life span in a compatible way.
> >
> > John
> > --
> >   John Polstra
> >   John D. Polstra & Co., Inc.                        Seattle, Washington
USA
> >   "Disappointment is a good sign of basic intelligence."  -- Chögyam
Trungpa
> >
> >
> > 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

Reply via email to