Re: Updated netfilter mark patch

From: Andrew Beverley <andy_at_andybev.com>
Date: Mon, 04 Oct 2010 07:45:08 +0100

On Mon, 2010-10-04 at 18:12 +1300, Amos Jeffries wrote:
> On 20/09/10 00:41, Andrew Beverley wrote:
> >>>>> I've moved it next to the headers check. I have also removed the error
> >>>>> message that was generated if they don't exist. However, this means that
> >>>>> if somebody explicitly sets --with-netfilter-conntrack and the libraries
> >>>>> don't exist, then it will silently fail. Is this the behaviour we want?
> >>>>
> >>>> Hmm, we at least want to MSG_NOTICE for both cases, with preferrably a
> >>>> hard error if its explicitly stated.
> >>>
> >>> There'll be the default AC_SEARCH_LIBS notice in any case, and then it
> >>> will also be shown later assuming --enable-zph-qos is set. I've just
> >>> realised though that by default the QOS functions are disabled. I
> >>> thought the new concept was that everything was enabled by default?
> >>> Should I change the default to enabled for --enable-zph-qos?
> >>
> >> Yes please.
> >
> > Now enabled by default.
> >
> > I have also decided that (as previously suggested) a miss option would
> > be useful in addition to the value preservation for a miss. This allows
> > a miss value to be set when Squid has been compiled without
> > libnetfilter-conntrack, and also makes it easier to set a miss value if
> > you're happy with a consistent value. I have therefore added this into
> > the latest patch (attached). The parameter is called 'miss' and it takes
> > precedence over the preserve-miss feature.
> >
> > I've not heard back from my 2 testers yet, and I am yet to use it in
> > anger myself, but I will give feedback on all these once I have it.
> >
> > Andy
> >
>
> Any news?
>

One of the testers has just now compiled a build with the patch in, so I
should hear back from him shortly; the other I have not heard from.

I am yet to use it in a production environment myself, but hope to do so
soon.

> Unless someone has a reason not to I'm going to commit this when the
> current trunk build issues are resolved.

I certainly wouldn't have any objections :)
Received on Mon Oct 04 2010 - 06:45:27 MDT

This archive was generated by hypermail 2.2.0 : Mon Oct 04 2010 - 12:00:03 MDT