On Sun, Jun 29, 2003 at 05:33:50AM +0200, Joel Wilsson wrote:
> [...]
> 
> Let's not get angry at each other over this. I think both Darren and 
> Thor
> raise some valid points, especially about the latest (?) ALTQ having
> hardcoded calls to pf.
> That's not a good design, unless you really do want to merge pf and ALTQ
> completely and not be able to use ALTQ separately. If I understood
> Kenjiro correctly, you don't intend to do that.
> 
> On the other hand, I don't see why it's so horrible to have to configure
> ALTQ through pfctl, even if you don't use pf for filtering. It doesn't
> seem to be a big deal.
> 
> What would change if the new ALTQ code was imported, and pf along with 
> it?
> 1) You would be able to choose among pf and IPFilter for packet 
> filtering.
> 2) You would no longer be able to configure ALTQ directly, but would 
> have
>    to go through pfctl instead.
> The first is good, the second seems like a minor problem (or feature).
> So I must be missing something here, let me know what.
> 
> If I understand Darren correctly, he's worried that ALTQ won't get a
> generic API that is not dependent on pf. That's reasonable, if he wants 
> to
> add support for ALTQ in IPFilter. Can you (itojun or Kenjiro) make that
> clear? Kenjiro wrote earlier that an API wouldn't be necessary, but I
> disagree. Will ALTQ once again be free from pf, ever, and if so,
> in how long? If IPFilter doesn't support ALTQ right now, it doesn't 
> matter
> if ALTQ will depend on pf for a while - but it should not stay that way.

Actually, this *is* the problem. The existing practice for NetBSD is that
code which has to interract with other piece of code doesn't get imported
before the API has been discussed and fixed; and I think this should not
change. Frequent API changes between different piece of code is a real
pain for peoples maintaining external patches.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 24 ans d'experience feront toujours la difference
--