pf + vimage patch

[Gleb Smirnoff]

On Thu, Jun 06, 2013 at 03:24:10PM +0300, Mikolaj Golub wrote:
M> > >> -VNET_DEFINE(u_long, pf_srchashsize);
M> > >> -#define	V_pf_srchashsize	VNET(pf_srchashsize)
M> > >> -SYSCTL_VNET_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN,
M> > >> -    &VNET_NAME(pf_srchashsize), 0, "Size of pf(4) source nodes hashtable");
M> > >> +u_long		pf_srchashsize;
M> > >> +SYSCTL_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN,
M> > >> +    &pf_srchashsize, 0, "Size of pf(4) source nodes hashtable");
M> > >>
M> > >
M> > > Why do you have to devirtualize these variables? Are per vnet
M> > > hashtables sizes not useful or do they cause issues?
M> > 
M> > Per VNET variables are not useful for pf_hashsize and pf_srchashsize
M> > since these values are RO and cannot be modified at runtime.
M> 
M> Indeed. I missed RDTUN flag.
M>  
M> > module unload is broken:( Maybe it can be fixed at a (bit) later date?
M> 
M> I don't think Gleb will be happy with this. Some time ago he removed
M> some vimage related stuff to prevent crashing on module unload (see
M> r229849). Actually your patch looks like a partial revert of that
M> commit. So I think you need to think about this issue from start. At
M> least it should not crash non-vimage kernel and there should be
M> understanding how to fix it for vimage kernel. Your approach with
M> keeping only one purge thread might make it simpler.

True. It is very much appreciated that you are working on vimage + pf,
but breaking module unload isn't an option.

When hacking on a part of kernel, having a possibility to avoid a reboot
after each compile is very important.

-- 
Totus tuus, Glebius.