Date: Sun, 11 Jun 2006 11:18:18 +0800 From: Julian Elischer <julian@elischer.org> To: Alex Lyashkov <shadow@psoft.net> Cc: Robert Watson <rwatson@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: jail extensions Message-ID: <448B8B7A.1020008@elischer.org> In-Reply-To: <1149969164.3215.66.camel@berloga.shadowland> References: <1149610678.4074.42.camel@berloga.shadowland> <448633F2.7030902@elischer.org> <20060607095824.W53690@fledge.watson.org> <200606070819.04301.jhb@freebsd.org> <4486E41B.4000003@elischer.org> <1149692184.3224.208.camel@berloga.shadowland> <4486EBBD.3090404@elischer.org> <1149757290.3222.44.camel@berloga.shadowland> <1149786697.3222.91.camel@berloga.shadowland> <44897693.5050306@elischer.org> <1149969164.3215.66.camel@berloga.shadowland>
next in thread | previous in thread | raw e-mail | index | archive | help
Alex Lyashkov wrote: >÷ ðÔÎ, 09.06.2006, × 16:24, Julian Elischer ÐÉÛÅÔ: > >>Alex Lyashkov wrote: >> >> >>>>2) at MOD_LOAD case run loop for each prisons and init private data for >>>>this module at all contexts. At this way module always 'exist' at all >>>>contexts. >>>>and disable module compiling (loading) when module don`t marked jail >>>>safe. >>>> >>>> >>>> >>>example for this way. >>>http://cvs.freevps.com/index.cgi/kernel/include/linux/freevps/s_context_xfrm.h?rev=1.3 >>>http://cvs.freevps.com/index.cgi/kernel/net/ipv4/ah4.c?rev=1.3 >>>ah4_init/ah4_fini functions. >>> >>> >>> >>this is the bit that is obvious. >> >>The hard bit is the non obvious difficulty of changing all existing >>modules in such away that >>they can be compiled both in the new way, and in a way that they are >>still compiled to the old way. >> >>You need to put all the currently global variables into a structure that >>can be instantiated >>for each jail, but in order to make this continue to work in the >>existing system, they still need to >>be compiled as a global when the normal buold is made. >> >>for this reason Marco and I were looking at various macros that can be >>defined to >>allow the variables to be compiled both ways. >> >>For example : >> >> >>int xx; >>static int yy; >>struct a { >> int aa; >> int bb; >>} cc; >> >>might become: >> >>VM_GLOBAL_START(modname) >> int xx; >> VMG_STATIC int yy; >> struct a { >> int aa; >> int bb; >> } cc; >> VM_GLOBAL_STOP(modname) >> >> >>You would access these as: >> VM_GLOBAL(modname, yy) = 2 >> foobar( VM_GLOBAL_STRUCT(cc, modname)->bb); >> >>or similar. >> >> >> >> >And I can`t find any benefits of give up old way when create >per module >struct module_data_$name { > int xx; > int yy; > struct a { > int aa; > int bb; > } cc; >}; >and use access as $name_data(context, yy) = 2. >for non jail kernel it`s should be converted to always access via >prison0. >main difficulty is convert access to variables to use macros, not are >create struct. > >is anybody can review my patch and point me any wrong parts > It's not a technical problem. It's the fact that when we introduce these things we always try to do it is a way so that there is a period where both old and new can co-exist. It would also be useful to have a set of macros (similar to the current SYSINIT) that make this easy to do. If you do this then you are adding two indirections to every global access as you need to access the struct via the current jail. people who compile this out are not likely to want to have that set of indirections for no purpose, especially during the settl-down eriod when it is new. If you want to not make it optional then, yes, but that in general is not how most large new work is done. And expect people to complain bitterly about any slow-down you introduce for people who don't want that fearture. ESPECIALLY in networking.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?448B8B7A.1020008>