Upgrading FreeBSD to use the NEW pf syntax.

Paul Webster paul.g.webster at googlemail.com
Sat Nov 24 14:11:35 UTC 2012


I only really need one question answered in honesty;

I personally think that by forking our own version of PF we have  
essentially made something totally different to what everyone wants to  
use. Which is fine, but because of that development of new features have  
dropped behind.

If we had kept up with OpenBSD's version even if we trailed it by one  
MAJOR release; at least part of the development would have been done.

So now we end up in a situation where we have these firewalls,  
IPFW2,ipf,pf(modded) and users wanting the newer features of OpenBSD's pf.  
So timewise the fork of pf may have actually cost more in time rather than  
less.

I don't however think the 'solution' to the problem is just to say no to  
the userbase by not even trying to port across the newer pf. I think we  
should look at bringing it across, slowly and seeing what the uptake is  
like; in a few MAJOR releases we can start to look at which of the  
firewalls realistically are not used that much and should be deprecated.

On Wed, 21 Nov 2012 15:20:19 -0000, Ermal Luçi <eri at freebsd.org> wrote:

> On Wed, Nov 21, 2012 at 3:52 PM, Gleb Smirnoff <glebius at freebsd.org>  
> wrote:
>
>> On Wed, Nov 21, 2012 at 03:44:13PM +0100, Ermal Lu?i wrote:
>> E> Cherry-picking would be when tehre is reasonable similarities.
>> E> Also another argument to do this would be simplicity on locking as  
>> well
>> as
>> E> i told you when you started the changes.
>>
>> You were wrong. OpenBSD doesn't move towards SMP model. Locking more
>> recent pf is not simplier, but the opposite.
>>
>>
> I am sorry but you are asking arguments i already have given you.
> You didn;t listen once and i do not expect this time as well.
>
>
>> E> Though i am open to work together on this to merge the new syntax
>> thorugh a
>> E> whole bulk merge rather than cherry-pick.
>>
>> How many bugs have you closed after the previous bulk import? Why should
>> we expect anything good from new import if the previous one was a PITA?
>>
>>
> Well you have used it for your work so it was not so PITA.
> Most of the ones you closed had message 'This is to old to be true'; 'I
> have re-written PF and this should be fixed'.
>
>
>> And still I don't see any answer on the question: what exact features or
>> perfomance improvements are we going to obtain from "the new pf"?
>>
>>
> See above.
>
>
>> E> You already have 'broken' some functionality as if-bound in FreeBSD
>> 10.x so
>>
>> Is there any PR filed on that? I didn't even receive a mail about that.
>>
>>
> I really do not think you do the right approach or the right  
> communication
> on this.
> Sorry for replying to you ;).
>
>
>> --
>> Totus tuus, Glebius.
>>
>
>
>


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/


More information about the freebsd-current mailing list