|
|
|
|
|
|
| Author |
Message |
Robert Watson
*nix forums Guru Wannabe
Joined: 22 Mar 2002
Posts: 218
|
 Posted: Thu Jun 08, 2006 11:32 am Post subject:
Re: jail extensions
|
|
|
On Wed, 7 Jun 2006, Brooks Davis wrote:
| Quote: | It's not clear to me that we want to use the same containers to control all
resouces since you might want a set of jails sharing IPC resources or being
allocated a slice of processor time to divide amongst them selves if we had
a hierarchical scheduler. That said, using a single prison structure could
do this if we allowed the administrator to specifiy a hierarchy of prisons
and not necessicairly enclose all resources in all prisons.
|
When looking at improved virtualization support for things like System V IPC,
my opinion has generally been that we introduce virtualization as a primitive,
and then have jail use the primitive much in the same way it does chroot.
This leaves flexibility to use it without jail, etc, but means we have a
well-understood and well-defined interaction with jail.
Robert N M Watson
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
 |
Alex Lyashkov
*nix forums beginner
Joined: 06 Jun 2006
Posts: 10
|
|
| Back to top |
|
|
Julian Elischer
*nix forums Guru Wannabe
Joined: 20 Mar 2002
Posts: 279
|
| Posted: Fri Jun 09, 2006 1:24 pm Post subject:
Re: jail extensions
|
|
|
Alex Lyashkov wrote:
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.
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Marko Zec
*nix forums beginner
Joined: 23 Oct 2002
Posts: 7
|
| Posted: Fri Jun 09, 2006 2:20 pm Post subject:
Re: jail extensions
|
|
|
On Friday 09 June 2006 13:24, Julian Elischer wrote:
| Quote: | 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_xf
rm.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);
|
One of the questions I have no answers to is what should we do with the
"static" modifier semantics in a virtualized world order. I.e. once th e
virtualized symbols are placed in a structure generated by whatever macros we
design, it will become difficult to efficiently discriminate between globally
and locally visible parts of that structure...
Marko
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Alex Lyashkov
*nix forums beginner
Joined: 06 Jun 2006
Posts: 10
|
| Posted: Sat Jun 10, 2006 7:52 pm Post subject:
Re: jail extensions
|
|
|
÷ ðÔÎ, 09.06.2006, × 16:24, Julian Elischer ÐÉÛÅÔ:
| Quote: | 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 ?
--
Alex Lyashkov <shadow@psoft.net>
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Julian Elischer
*nix forums Guru Wannabe
Joined: 20 Mar 2002
Posts: 279
|
| Posted: Sun Jun 11, 2006 3:18 am Post subject:
Re: jail extensions
|
|
|
Alex Lyashkov wrote:
| Quote: | ÷ ðÔÎ, 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.
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Alex Lyashkov
*nix forums beginner
Joined: 06 Jun 2006
Posts: 10
|
| Posted: Sun Jun 11, 2006 5:23 pm Post subject:
Re: jail extensions
|
|
|
| Quote: |
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
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Jeremie Le Hen
*nix forums beginner
Joined: 17 Dec 2004
Posts: 10
|
| Posted: Fri Jul 14, 2006 10:03 am Post subject:
Re: [fbsd] Re: jail extensions
|
|
|
Hi,
On Thu, Jun 08, 2006 at 12:32:42PM +0100, Robert Watson wrote:
| Quote: | On Wed, 7 Jun 2006, Brooks Davis wrote:
It's not clear to me that we want to use the same containers to control
all resouces since you might want a set of jails sharing IPC resources or
being allocated a slice of processor time to divide amongst them selves if
we had a hierarchical scheduler. That said, using a single prison
structure could do this if we allowed the administrator to specifiy a
hierarchy of prisons and not necessicairly enclose all resources in all
prisons.
When looking at improved virtualization support for things like System V
IPC, my opinion has generally been that we introduce virtualization as a
primitive, and then have jail use the primitive much in the same way it
does chroot. This leaves flexibility to use it without jail, etc, but means
we have a well-understood and well-defined interaction with jail.
|
IMHO, it is worth having virtualization primitives wherever it is
required and make jails use them. This can be the case for the
System V IPC as well as for the network stack (think of Marko's work).
My point is that the usability of virtual network stacks remains
interesting outside the jail framework and should be able to be managed
from its own userland tool (though the latter should probably not be
able to destroy a virtual network stack associated with a jail).
However I don't think that IPC are worth virtualizing outside a
jail framework.
My two cents.
Best regards,
--
Jeremie Le Hen
< jeremie at le-hen dot org >< ttz at chchile dot org >
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Brooks Davis
*nix forums addict
Joined: 14 Jun 2002
Posts: 97
|
| Posted: Fri Jul 14, 2006 4:21 pm Post subject:
Re: [fbsd] Re: jail extensions
|
|
|
On Fri, Jul 14, 2006 at 12:03:33PM +0200, Jeremie Le Hen wrote:
| Quote: | Hi,
On Thu, Jun 08, 2006 at 12:32:42PM +0100, Robert Watson wrote:
On Wed, 7 Jun 2006, Brooks Davis wrote:
It's not clear to me that we want to use the same containers to control
all resouces since you might want a set of jails sharing IPC resources or
being allocated a slice of processor time to divide amongst them selves if
we had a hierarchical scheduler. That said, using a single prison
structure could do this if we allowed the administrator to specifiy a
hierarchy of prisons and not necessicairly enclose all resources in all
prisons.
When looking at improved virtualization support for things like System V
IPC, my opinion has generally been that we introduce virtualization as a
primitive, and then have jail use the primitive much in the same way it
does chroot. This leaves flexibility to use it without jail, etc, but means
we have a well-understood and well-defined interaction with jail.
IMHO, it is worth having virtualization primitives wherever it is
required and make jails use them. This can be the case for the
System V IPC as well as for the network stack (think of Marko's work).
My point is that the usability of virtual network stacks remains
interesting outside the jail framework and should be able to be managed
from its own userland tool (though the latter should probably not be
able to destroy a virtual network stack associated with a jail).
However I don't think that IPC are worth virtualizing outside a
jail framework.
|
I could definitly use the ability to virtualize IPC inside a lighter
container then a jail. I'd like to be able to tie them to jobs in a
batch system managed by Sun Grid Engine so I can constrain resources on
a per-job basis and insure the no IPC objects outlive the job.
-- Brooks |
|
| Back to top |
|
|
Julian Elischer
*nix forums Guru Wannabe
Joined: 20 Mar 2002
Posts: 279
|
| Posted: Fri Jul 14, 2006 8:44 pm Post subject:
Re: [fbsd] Re: jail extensions
|
|
|
Brooks Davis wrote:
| Quote: | On Fri, Jul 14, 2006 at 12:03:33PM +0200, Jeremie Le Hen wrote:
Hi,
On Thu, Jun 08, 2006 at 12:32:42PM +0100, Robert Watson wrote:
On Wed, 7 Jun 2006, Brooks Davis wrote:
It's not clear to me that we want to use the same containers to control
all resouces since you might want a set of jails sharing IPC resources or
being allocated a slice of processor time to divide amongst them selves if
we had a hierarchical scheduler. That said, using a single prison
structure could do this if we allowed the administrator to specifiy a
hierarchy of prisons and not necessicairly enclose all resources in all
prisons.
When looking at improved virtualization support for things like System V
IPC, my opinion has generally been that we introduce virtualization as a
primitive, and then have jail use the primitive much in the same way it
does chroot. This leaves flexibility to use it without jail, etc, but means
we have a well-understood and well-defined interaction with jail.
IMHO, it is worth having virtualization primitives wherever it is
required and make jails use them. This can be the case for the
System V IPC as well as for the network stack (think of Marko's work).
My point is that the usability of virtual network stacks remains
interesting outside the jail framework and should be able to be managed
from its own userland tool (though the latter should probably not be
able to destroy a virtual network stack associated with a jail).
However I don't think that IPC are worth virtualizing outside a
jail framework.
I could definitly use the ability to virtualize IPC inside a lighter
container then a jail. I'd like to be able to tie them to jobs in a
batch system managed by Sun Grid Engine so I can constrain resources on
a per-job basis and insure the no IPC objects outlive the job.
-- Brooks
I think that the term "jail" needs to be replaced by something else in |
this context..
maybe a "virtual context".. virtual contexts would have the option of
virtualising
different parts of the system.
for example they would have the option of whether or not to have a
chroot, or their own
networking stack, or their own process space..
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Brooks Davis
*nix forums addict
Joined: 14 Jun 2002
Posts: 97
|
| Posted: Fri Jul 14, 2006 11:25 pm Post subject:
Re: [fbsd] Re: jail extensions
|
|
|
On Fri, Jul 14, 2006 at 01:44:26PM -0700, Julian Elischer wrote:
| Quote: | Brooks Davis wrote:
On Fri, Jul 14, 2006 at 12:03:33PM +0200, Jeremie Le Hen wrote:
On Thu, Jun 08, 2006 at 12:32:42PM +0100, Robert Watson wrote:
On Wed, 7 Jun 2006, Brooks Davis wrote:
It's not clear to me that we want to use the same containers to control
all resouces since you might want a set of jails sharing IPC resources
or being allocated a slice of processor time to divide amongst them
selves if we had a hierarchical scheduler. That said, using a single
prison structure could do this if we allowed the administrator to
specifiy a hierarchy of prisons and not necessicairly enclose all
resources in all prisons.
When looking at improved virtualization support for things like System V
IPC, my opinion has generally been that we introduce virtualization as a
primitive, and then have jail use the primitive much in the same way it
does chroot. This leaves flexibility to use it without jail, etc, but
means we have a well-understood and well-defined interaction with jail.
IMHO, it is worth having virtualization primitives wherever it is
required and make jails use them. This can be the case for the
System V IPC as well as for the network stack (think of Marko's work).
My point is that the usability of virtual network stacks remains
interesting outside the jail framework and should be able to be managed
from its own userland tool (though the latter should probably not be
able to destroy a virtual network stack associated with a jail).
However I don't think that IPC are worth virtualizing outside a
jail framework.
I could definitly use the ability to virtualize IPC inside a lighter
container then a jail. I'd like to be able to tie them to jobs in a
batch system managed by Sun Grid Engine so I can constrain resources on
a per-job basis and insure the no IPC objects outlive the job.
I think that the term "jail" needs to be replaced by something else in
this context..
maybe a "virtual context".. virtual contexts would have the option of
virtualising
different parts of the system.
for example they would have the option of whether or not to have a
chroot, or their own
networking stack, or their own process space..
|
This sounds good to me if we could do it in a way that performed
decently.
-- Brooks |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Sun Nov 23, 2008 10:57 am | All times are GMT
|
|
Actress | Agencia de viagens | Credit Cards UK | Credit Report | RC Boats
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
BSD
»
FreeBSD
»
mail-lists
»
Architecture
