In some mail from Kenjiro Cho, sie said:
> 
> My impression is that API is not so important here.

I think it is - always.

Currently, based on what I've seen in OpenBSD and read here, you
should not have a kernel configuration like this:

pseudo-device ipfilter
#pseudo-device pf
options ALTQ

because various ALTQ files include pf related header files for things
like "struct pf_altq".  ALTQ should be providing the interface to be
used by packet classifiers, not the other way around.  I say "should
not" because strictly speakingn header files can be used like that
but it doesn't strike me as being a "Good Thing"(tm).  Anyway, where
you are aiming to support a 1:N relationship, the "1" should be
providing the interface, not one of the N's.

Maybe I'm just more concerned about things architecturally and looking
for a good design...

> The tagger and the consumer share only tag values.  All you need is a
> mechanism to map a string label to the corresponding tag value.
> In pf, pf creates and keeps mapping, and provides a function to
> retrieve tag values.
> 	u_int16_t pf_tagname2tag(char *tagname);
> So, if IPFilter provides a similar function, we can make use of
> IPFilter.

That suggests to me that IPFilter/pf couldn't co-exist if they were
both required to provide the same function name as part of an interface,
correct ?

Looking at ALTQ from KAME (I just did a cvs update from kame), there
is currently no use of m_tag that is found in the OpenBSD source.
Is this because changes are still pending being pulled up into KAME
from OpenBSD to support this ?

And if someone were to update the NetBSD altq with what appears to be
-current ALTQ from KAME, there would be no need for pf, right ?

Hopefully this means any integration/API between packet classifiers
and ALTQ is still open for discussion :)

> There's no conspiracy behind it.  It's just because I didn't have a
> chance to drink beer with you :)

Damn, I'm never in the right place at the right time!
;)

Darren