On Mon, Jun 30, 2003 at 01:11:56PM +1000, Darren Reed wrote:
> Why doesn't pftag_unref() do the deletion when the ref count becomes
> 0 anyway ?  Looking at pftag_purge(), there should be no need for it.

it's been some time that I wrote that, but it was intentional. If 
memory serves me right there is quite some likeliness that we'll need
the same tag again shortly after the refcount reached zero. So we leave it
there until the whole operation (ruleset reload, for example) is done, and 
purge the ones that are still zero afterwards. That should prevent 
fragmentation in the ID range.
hmm, given that the old ruleset isn't deleted until the new is in 
place that shouldn't be an issue. Had to dig deeper into it to get 
what I was after when doing it this way again.
Another issue is that the ruleset activation has to be done in 
splnet() and thus should be as fast as possible, while we safely can 
do the actual purge later outside the splnet() block.

> pftag_tag2tagname() should return a boolean, well, it might if it was
> actually used, but nothing calls pf_tag2tagname(), either.

pf_tag2tagname() is used from the bridge code in OpenBSD. The bridge 
filters can tag packets as well, and pf can filter/queue/whatever 
based on those tags.

> Why on earth do I get the feeling I'm debugging OpenBSD stuff when I
> shouldn't have to ? ...  don't they have any sort of review process?

darren, please. Our review process is well known.
There's reasons behind that is implemented that way. They may not be 
totally obvious at a quick glance, yes...

-- 
Henning Brauer, BS Web Services, http://bsws.de
hb@bsws.de - henning@openbsd.org
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)