jail extensions

[Alex Lyashkov]

> 
> 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.
> 
my change log has record - 'option JAIL' added to kernel config, 
without it - kernel build at "old" way.
In future, after all of need modules will be rewrite to support jail, -
this behaviour can be changed and to disable only codepath where jail
add overhead (for my FreeVPS project it`s only L2 routing for separate
packets between context) or disable code only used with jail.


-- 
FreeVPS Developers Team  http://www.freevps.com
Positive Software        http://www.psoft.net