--pgp-sign-Multipart_Mon_Jul_25_20:49:15_2005-1
Content-Type: text/plain; charset=US-ASCII

>>>>> "mh" == Martin Husemann <martin@duskware.de> writes:

    mh> Then you could start shouting at the ALTQ people who did not
    mh> come up with a sane classifier API despite promising since
    mh> 2003/6 ;-)

respectfully, I think you're maybe misled by being on the edge of the
debate.  One of the things explained in the thread, the API exists
already---it is mbuf tags, the same used for marking ipsec processing
and supposedly used by the firewalls so they don't filter their own
return-icmp and return-rst packets.  The additional ``API'' beyond
mbuf tags is exactly two functions, and everyone agrees what they need
to be: (1) translate queue name to mbuf tag number, (2) translate mbuf
tag number to queue name.  These are the only two functions that join
PF and ALTQ together, and the only two functions needed to join
ipfilter and PF's ALTQ together.  The objections to the APIs offered
in June 2003 were:

 1. the function names contain the text pf_

 2. what .c file do the functions belong in (Darren found the .c file
    itojun chose unacceptable, but didn't suggest a better place.)

 3. ``nice try itojun but patches still need more work.''

 4. We hate OpenBSD since they kicked out all developers who refused
    to quit working on NetBSD and think being dependent on PF is
    dangerous.  (fine, but nothing to do with PF/ALTQ now that PF is
    imported)

There is really no other objection since the needed ``API'' is so
simple and so undisputed, which was exactly the point here:

 http://mail-index.netbsd.org/tech-net/2003/06/27/0017.html

I don't understand how this simple issue was so successfully clouded.

Neither Darren nor any other detractor offered a line of code of his
own, nor any reasonable non-obstructionist constructive guidance.  Yet
I'm convinced that without changing a line of source outside ipfilter,
and without inconveniencing oneself further than having to type the
politically humiliating letters 'pf_', that ipfilter could classify
packets for PF/ALTQ with the PF/ALTQ patches _as they stand now_.  And
it is quite possible to load ALTQ classes without enabling PF.  But
asking the people who have done work on PF/ALTQ to add a major
enhancement to ipfilter, including defining new grammar, just so
importing their work doesn't make ipfilter look bad, is unreasonable.
People who use ipfilter need to do that work, indeed are the only
people who understand ipfilter code enough to do it successfully.
Otherwise it is just a strategic obstruction.  And at this point the
obstruction is so successful that I think any ``API'' proposed (any
other choice of .c file and name for the mere two functions needed)
will be deemed unacceptable until the overall patch delivers ipfilter
working with ALTQ.

The detractors' other objection is that ALTQ is configured by a
program that has 'pf' in its name and reads configuration from a file
called 'pf.conf', so of course it is tied to PF and can never work
with ipfilter unless it's massively rearchitected.  However, the ALTQ
verbs within the file are completely seperate from the PF verbs, and
in fact pfctl will fail if ALTQ verbs and PF verbs are intermixed at
all---they must be separated into ``stanzas''.  If you don't like
pfctl and pf.conf because they contain the letters 'pf', then here:

/usr/sbin/altqctl:
-----8<-----
#! /bin/ksh

(
        while [ $# -ne 0 ]; do
            if [ X"$1" = X-N -o X"$1" = X-R -o X"$1" = X-O ]; then
               echo "$1 is invalid for altqctl"
               exit 1
            fi
            shift
        done
)

altqconf="$(
        while [ $# -ne 0 ]; do
            if [ X"$1" = X-f ]; then
                break
            fi
            shift
        done
        if [ $# -eq 0 ]; then
            echo "-f /etc/altq.conf"
        fi
        )"

/usr/sbin/pfctl -A $altqconf "$@"
-----8<-----

This will make altqctl read ALTQ options only from /etc/altq.conf, and
configure ALTQ without enabling the PF firewall, after which it will
happily schedule packets if some ipfilter supporter will do the work
of making ipfilter add mbuf tags to packets.

Shall I send-pr with my shell script that solves this ``muddled
configuration file'' architectural deficiency?  One could make 'pfctl'
check argv[0] as well, but the point is this is mearly fashion and
pride, not a real architectural problem, not a reason to hold up a
patch for over two YEARS.

The other problem is, to my impression the people who do not want ALTQ
imported are not using the current old-ALTQ.  The people making and
supporting the patches are, obviously, using it.  The people reviewing
code pay no attention to it because they aren't using it themselves,
yet their only non-political reason for rejecting the patches is to
preserve old-ALTQ, something they also are not using themselves, that
in fact basically no one is using because it is bitrotted and doesn't
work well.  I think it's not right.

And the final problem is, ALTQ already has its own non-ipfilter
classifier, but nobody has a problem with that bogus architecture.
They only have a problem if the non-ipfilter classifier needed by ALTQ
happens to be PF.  In fact, as Kenjiro Cho pointed out, it's much
easier to make ipfilter work with PF/ALTQ than to work with the
current old-ALTQ, because the old ALTQ doesn't use mbuf tags, and the
new one does.  It's hypocricy, and all the worse since the underlying
motives seem to me quite naked.

Anyway, I'm sorry, but after helping people with the onerous task of
getting pflkm working, explaining this on mailing lists, and
struggling through a bunch of ipfilter bugs in the 2.0_BETA stage many
of which are still open or were closed without resolution, only to
find that with 3.0 I'm again without ALTQ, I'm just tired of fighting
this.  In fact it's a real personal weakness, my tendency toward
flamewar bullshit, that I spent the time writing this email rather
than doing what I'm supposed to be doing right now.  I need to move on
and get this link working.  I can't keep losing two-year old arguments
on mailing lists.

--pgp-sign-Multipart_Mon_Jul_25_20:49:15_2005-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQCVAwUAQuWIi4nCBbTaW/4dAQJSrwQAjVLEcTgClbjPkeEg4G6XL32QGG6wbrqg
DJNOi1ykX1L+ZZzcCidJmt816omo1qF6OVlMM5nUHZApYuWlNiM24WmpZQ9QF8YJ
IdobXHSrhnaSw2XgIYDX+nEif3VqjG+ET54ivBPknMDYBBTg9TFvEVXFWAOB0DZv
cRrd/ibku1o=
=DGoP
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Mon_Jul_25_20:49:15_2005-1--