>> 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.

	API for ALTQ itself is open to any userland program, via ioctl.
	i worry about support issues (config syntax and such) if both ipfilter 
	and PF were to include ALTQ controller functionality.

itojun