[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ALTQ/FreeBSD] Re: CFR: MFC of mtags (fwd)
This was recently brought up on freebsd-net. I thought I'd pass it on,
since we may be affected. If need be, I can point out the detailed
changes Sam's patch enttails, but I wanted to make sure first that we
are indeed affected, which I am far from being sure of. (Sam mentioned
KAME wasn't affected, but I doubt he was thinking of altq itself.) I
guess I could go ahead and refresh my memory on altq's internals (which
I'm going to do regardless), but I wanted to branch this discussion in
here.
And by the way, 5.0 is definitely in code freeze, so altq can't make it
to FreeBSD before 5.1 at the earliest.
--
Nicolas Christin
Ph.D. Candidate, University of Virginia, Computer Science
http://www.cs.virginia.edu/~nicolas
---------- Forwarded message ----------
Date: Fri, 22 Nov 2002 09:26:04 -0800
From: Sam Leffler <sam@errno.com>
To: Luigi Rizzo <rizzo@icir.org>, John Polstra <jdp@polstra.com>
Cc: net@FreeBSD.ORG
Subject: Re: CFR: MFC of mtags
> 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$52557f42@errno.com>, Sam Leffler
> > <sam@errno.com> 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 majordomo@FreeBSD.org
> > with "unsubscribe freebsd-net" in the body of the message
>
>
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
_________________________________________________________________
Send 'unsubscribe freebsd-altq' to listar@rofug.ro to unsubscribe