Why merging recent OpenBSD PF code is not easy (was Re: FOLLOW-UP)

[Bjoern A. Zeeb]

On 08 Dec 2014, at 02:22 , Jim Thompson <jim at netgate.com> wrote:

>> On Dec 7, 2014, at 5:09 PM, Martin Hanson <greencoppermine at yandex.com> wrote:
>> 
>> Seems like you have missed the whole point, nobody can sort it out now!
> 
> No, you’re missing the point.
> 
> The codebase has forked, and it’s unlikely that anyone who is working on (or in a position to direct work on) pf believes that the correct course of action is to reverse at this point, and follow your prescriptive.

I have not read all your references but there are more points one could possibly consider:

- backward compatibility;  FreeBSD tries not to screw users over with every new major release and constantly changing syntax and old firewall rules no longer working are just not an option for us;  you can “fix” this by writing a backward compat parser and adjusting the code to support all the stuff still;  just a lot more extra work on code you don’t maintain and thus making it hard to sync.

- the #ifdefs were indeed just not sustainable and a major pain reading the code; that could have been reduced but frankly prevented us for too long to work on the code. V_irtualisation is just another code mangler.

- the tight integration of pf in OpenBSD with the rest of their network stack started to suit the more generic FreeBSD model less and less.  We can’t just do that unless we drop other firewalls and screw a lot of commercial user base.

- There is another major pf player in the game who wasn’t mentioned yet, and that’s Apple.  Has anyone considered looking at their implementation shipping on millions of devices, requiring similar “API stability” as FreeBSD would love to support?


Just a few things from the top of my head.

— 
Bjoern A. Zeeb                                  Charles Haddon Spurgeon:
"Friendship is one of the sweetest joys of life.  Many might have failed
 beneath the bitterness of their trial  had they not found a friend."