Cy Schubert wrote:
In message <53ccf596.1070...@yandex.ru>, "Andrey V. Elsukov" writes:
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--EITUmaAVUtsHLdssNwHpA0G0W8jTQ9d3L
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 20.07.2014 18:15, Maxim Khitrov wrote:
In my opinion, the way forward is to forget (at least temporarily) the
SMP changes, bring pf in sync with OpenBSD, put a policy in place to
follow their releases as closely as possible, and then try to
reintroduce all the SMP work. I think the latter has to be done
upstream, otherwise it'll always be a story of diverging codebases.
Furthermore, if FreeBSD developers were willing to spend some time
improving pf performance on OpenBSD, then Henning and other OpenBSD
developers might be more receptive to changes that make the porting
process easier.
Even if you just drop current PF from FreeBSD, there is nobody, who want
to port new PF from OpenBSD. And this is not easy task, as you may
think. Gleb has worked on rewriting PF more than half year. So, return
back all improvements after import will be hard enough and, again,
nobody want to do it. :)
One way or another something needs to be done and agreed it would be a lot
of work. Our options are,
a) Import OpenBSD pf thereby throwing away our current investment in pf.
All our work to get it up to snuff with our IP stack, SMP, and VIMAGE would
be all for naught. We do get a new pf though. Won't be a quality port
though. Personally, not my #1 option.
b) Merge updates from OpenBSD pf to our pf. Once again a lot of work but we
do save the work we put into our pf. Once again a lot of work. We'd be
introducing incompatibility.
c) Do nothing. It goes without saying that pf would suffer rot and
eventually we would need to do something.
d) Yank pf from tree. An option but probably not a great one. We do have
two other packet filters in the kernel (ipfw and ipfilter) however they are
different beasts with different capabilities. I think the reason we have
the packet filters we do have is for the capabilities they bring to the
table. I for one have run more than one in the same kernel because each has
different capabilities.
e) We could add capability to pf on a piecemeal basis. Option (b) but as
time permits. Remember, people have jobs and commitments. Funding would
help address this.
f) Finally, how does NetBSD's npf compare to OpenBSD's pf? Is it more
compatible with our IP stack? Could this be an option?
Anything we do should work with VIMAGE and be able to handle nat66 as well.
Hello Cy;
Finally a voice I recognize. If I remember correctly you stepped up to
the plate earlier this year and did for ipfilter the same kind of things
this thread is talking about for pf. IE; apply upstream maintenance and
convert to FreeBSD standards. I think your work was a BSD fork of
Darrow's ipfilter which from this point on all upstream maintenance must
be hand merged into the BSD fork. I am a long time ipfilter user and
thank you for your dedication and work ethics getting the updated
ipfilter into 10.0 and 9.3 so quickly.
So as someone who has been there and done that already you have unique
experience to really know the size of the task in hours to accomplish a
pf upgrade. Could you list the tasks and hours it took you to perform
the ipfilter upgrade so readers can have a real insight into what they
are asking for?
I agree with your option "e" above, but I would re-word it this way.
Using the pf fork we already have in place, hand merge upstream
differences in piecemeal chunks as time permits. The openbsd new syntax
being the first chunk, closely followed by VIMAGE awareness.
When it comes to someone volunteering to do the work, many of us would
step up, but the fact is only a very very few people have the coding and
kernel knowledge to even consider doing this.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
