Date: Tue, 19 May 2009 13:31:34 -0700 From: Julian Elischer <julian@elischer.org> To: John Baldwin <jhb@freebsd.org> Cc: "Bjoern A. Zeeb" <bz@freebsd.org>, src-committers@freebsd.org, FreeBSD virtualization mailing list <freebsd-virtualization@freebsd.org> Subject: Re: svn commit: r192351 - head/sys/netinet Message-ID: <4A131726.6010003@elischer.org> In-Reply-To: <200905191330.54024.jhb@freebsd.org> References: <200905182234.n4IMYifY077079@svn.freebsd.org> <200905190819.12407.jhb@freebsd.org> <4A12E85B.7050107@elischer.org> <200905191330.54024.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >>>> URL: http://svn.freebsd.org/changeset/base/192351 >>>> >>>> Log: >>>> 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 > default_to_accept >>> (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). :-) The
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A131726.6010003>