John Baldwin wrote:
On Tuesday 19 May 2009 1:11:55 pm Julian Elischer wrote:
John Baldwin wrote:
On Monday 18 May 2009 6:34:44 pm Bjoern A. Zeeb wrote:
Author: bz
Date: Mon May 18 22:34:44 2009
New Revision: 192351

  Revert the logical change of r192341.
net.inet.ip.fw.one_pass is a classic ip_input.c variable and is used in
  the pfil and bridge code as well. As ipfw is loadable we need to always
  provide it.  That is the reason why it lives in struct vnet_inet and
  not in struct vnet_ipfw.
Gah, I had thought I had seen it in vnet_ipfw when adding
(as at first I had looked into making default_to_accept per-image but tunables + VIMAGE don't mix).
we need to look at this.. what does it MEAN to have a tunable and multiple images? my guess is that normal tunables are only valid for teh base image, but that one might have a way to set the 'tunables' for one's child images.. possibly by setting them in one's environment?

Do you have a kernel environment per vimage? If not, you could still have per-vimage variables that are settable via tunables look at kenv during vimage creation to parse any tunables perhaps. However, that is possibly tricky since you can sometimes use sysctl.conf to override a setting done via loader.conf and in that case, what value should a new vimage get

One could make the argument that tunables are set from outside
the base jail (i.e. at boot), and that the equivalent should
exist for each image/jail, where what is outside the jail is
the parent jail. We do not have a kernel environment per jail,
but I think that is because we haven't thought of it until now.

I'd suggest that just as you inherit new environment values
from a parent process, you could inherrit a 'changed' kernel
environment from a parent image, and in fact a parent might want to send you differnet vale of something (e.g. linux uname value).


_______________________________________________ mailing list
To unsubscribe, send any mail to 

Reply via email to