[patch] ipfw_nat as a kld module

[Vadim Goncharov]

Hi piso at FreeBSD.org! 

On Fri, 29 Feb 2008 16:41:44 +0100; piso at FreeBSD.org wrote about 'Re: [patch] ipfw_nat as a kld module':

>>>> * struct ip_fw_chain moved to .h and no longer static, is this good?
>>>>   I suggest to move into it's own static chain in module, see next
>>> the symbol is used outside it's originating file
>> 
>> Is it needed if LIST_HEAD will be in its own module?
> every modification/access to layer3_chain lock is arbitrated via its
> own rwlock(), thus to answer your question, yes, there are places
> where we would need access to layer3_chain

Umm, why? Dummynet doesn't need this access, for example.

>>> that's something i thought about, but i didn't see any tangible improvement
>>> to this modification, cause part of ipfw_nat would still be called from 
>>> ipfw2.c (see ipfw_ctl).
>> 
>> This could be fixed, too, as is done with dummynet, which is also configured
>> via ipfw(8). As it is HEAD, ABI can be broken and this will not be done via
>> ipfw_ctl().
> yes, but does it buy us anything? moreover, we would loose the ability
> to merge the work back to 7.x.

OK, this could be done after merging to 7.x to preserve ABI there. I think,
some time after ``ipfw nat'' is widely tested in 7.0-RELEASE to wait for
bugfixes to settle. May be a month or two.

What benefits?.. I've listed some in previous message, e.g. ability to change
code in NAT module without affecting main ipfw, like easily changing from LIST
to HASH, etc.

Of course, ``ipfw nat'' should be done this way from scratch, but while it's
to late for 7.x, 8.0 still could be split to gain other possible bonuses of
clean-architecture.

-- 
WBR, Vadim Goncharov. ICQ#166852181       mailto:vadim_nuclight at mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]