svn commit: r185880 - in vendor/pf/dist: authpf ftp-proxy man pfctl pflogd

Marko Zec zec at icir.org
Wed Dec 10 16:28:22 PST 2008


On Wednesday 10 December 2008 22:43:54 Max Laier wrote:
> On Wednesday 10 December 2008 22:02:35 Julian Elischer wrote:
> > Max Laier wrote:
> > > Author: mlaier
> > > Date: Wed Dec 10 20:59:26 2008
> > > New Revision: 185880
> > > URL: http://svn.freebsd.org/changeset/base/185880
> > >
> > > Log:
> > >   Import OPENBSD_4_3_BASE
> >
> > so, how do we go about virtualizing this?
> > and I don't like our chances of getting virtualized macros into the
> > openbsd sources....
>
> Yeah, most likely a no-go.  From what I understand, Marko has a
> virtualized version of what's in the tree now and I don't intend to
> void that work by blindly dumping the new version in head and have
> him deal with it.

I _had_ a virtualized version that become obsolete with the import of 
then new PF version around May 2007...  Given that virtualizing PF 
isn't quite a trivial task, I was reluctant to spent another full week 
or so on crunching the current version of PF that we have in the tree, 
just to see it becoming obsolete again and again.

> It will take some time to get the import done and I'll do it in my
> user dir. Once this is in somewhat usable shape I'll start looking at
> the V_ stuff and how to best go about merging it.  FWIW, it might be
> easier to virtualize the new version as it greatly reduces code
> duplication in some relevant areas.

Great!  So from my perspective by all means pls. go ahead and proceed 
with merging the latest PF to head, and by the time that will be done, 
we'll also have more than enough of virtualization infrastructure in 
the tree to justify another round of PF virtualization game.  

Of course we should start thinking on what tricks would be best suited 
for PF virtualization while still permitting code syncing with OpenBSD.

Marko

> If you are ready to commit the 2nd half of the vnet stuff in the
> meantime, please go ahead and do so.  I'll figure out how to deal
> with it.



More information about the svn-src-vendor mailing list