|
|
|
|
|
|
| Author |
Message |
Maxim Konovalov
*nix forums beginner
Joined: 23 Mar 2004
Posts: 15
|
 Posted: Tue Jun 06, 2006 4:31 pm Post subject:
Re: jail extensions
|
|
|
On Tue, 6 Jun 2006, 19:17+0300, Alex Lyashkov wrote:
| Quote: | Hello All,
I started to write some extension for jail. Global
idea is to write the complete virtual server solutions,
when each virtual server has its own resources and limits
of their usage.
Now implemented:
- all jail code compiled under 'options JAIL'
- separated uid hash
- separated SYSVIPC with limit IPC objects count
- process count limit
At first time I plan to implement file handles limit and
limit of the total disk usage per jail.
project homepage http://docs.freevps.com/doku.php?id=freebsd:index
|
I'd like to clarify Alex's point a bit: he wants to know his work is
acceptable by the project and could be merged. It's obvious it's
almost impossible to maintain that outside of the tree.
--
Maxim Konovalov
_______________________________________________
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: Wed Jun 07, 2006 2:03 am Post subject:
Re: jail extensions
|
|
|
Maxim Konovalov wrote:
| Quote: | On Tue, 6 Jun 2006, 19:17+0300, Alex Lyashkov wrote:
Hello All,
I started to write some extension for jail. Global
idea is to write the complete virtual server solutions,
when each virtual server has its own resources and limits
of their usage.
Now implemented:
- all jail code compiled under 'options JAIL'
- separated uid hash
- separated SYSVIPC with limit IPC objects count
- process count limit
At first time I plan to implement file handles limit and
limit of the total disk usage per jail.
project homepage http://docs.freevps.com/doku.php?id=freebsd:index
I'd like to clarify Alex's point a bit: he wants to know his work is
acceptable by the project and could be merged. It's obvious it's
almost impossible to maintain that outside of the tree.
I'd like to see him merge his project with Marco's . If so then I'd be |
more than happy
to see this stuff come in once it reaches a certain level of maturity.
Marco and I have been going over some possible macros that could be used
to help with
a lot of this and if the macros were used then some of the changes could
come in quite early
as they would compile out to NOPs for anyone not using the changes.
( and provide an easy target for removal if it eventually doesn't complete).
_______________________________________________
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: Wed Jun 07, 2006 5:59 am Post subject:
Re: jail extensions
|
|
|
÷ óÒÄ, 07.06.2006, × 05:03, Julian Elischer ÐÉÛÅÔ:
| Quote: | Maxim Konovalov wrote:
On Tue, 6 Jun 2006, 19:17+0300, Alex Lyashkov wrote:
Hello All,
I started to write some extension for jail. Global
idea is to write the complete virtual server solutions,
when each virtual server has its own resources and limits
of their usage.
Now implemented:
- all jail code compiled under 'options JAIL'
- separated uid hash
- separated SYSVIPC with limit IPC objects count
- process count limit
At first time I plan to implement file handles limit and
limit of the total disk usage per jail.
project homepage http://docs.freevps.com/doku.php?id=freebsd:index
I'd like to clarify Alex's point a bit: he wants to know his work is
acceptable by the project and could be merged. It's obvious it's
almost impossible to maintain that outside of the tree.
I'd like to see him merge his project with Marco's . If so then I'd be
more than happy
to see this stuff come in once it reaches a certain level of maturity.
Marco and I have been going over some possible macros that could be used
to help with
a lot of this and if the macros were used then some of the changes could
come in quite early
as they would compile out to NOPs for anyone not using the changes.
( and provide an easy target for removal if it eventually doesn't complete).
I focused with write flexible kernel API and create conception - any |
process run with own context. With 'jail2' all processes have
cred->pr_prison defined. As for me it`s allow easy use struct prison as
storage for any context related data such as uid hash, or diskquota
hash, limits info or other. Process count limit and separated uid hash
created as example to use this conception.
Same conception used at my other project - FreeVPS
(http://www.freevps.com/tracker.html).
Where i can see you and Marco work ?
--
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 |
|
|
Milan Obuch
*nix forums beginner
Joined: 15 Mar 2006
Posts: 3
|
| Posted: Wed Jun 07, 2006 6:59 am Post subject:
Re: jail extensions
|
|
|
On Wednesday 07 June 2006 07:59, Alex Lyashkov wrote:
| Quote: | ÷ óÒÄ, 07.06.2006, × 05:03, Julian Elischer ÐÉÛÅÔ:
Maxim Konovalov wrote:
On Tue, 6 Jun 2006, 19:17+0300, Alex Lyashkov wrote:
Hello All,
I started to write some extension for jail. Global
idea is to write the complete virtual server solutions,
when each virtual server has its own resources and limits
of their usage.
[ snip ]
project homepage http://docs.freevps.com/doku.php?id=freebsd:index
I'd like to clarify Alex's point a bit: he wants to know his work is
acceptable by the project and could be merged. It's obvious it's
almost impossible to maintain that outside of the tree.
I'd like to see him merge his project with Marco's . If so then I'd be
more than happy
to see this stuff come in once it reaches a certain level of maturity.
Marco and I have been going over some possible macros that could be used
to help with
a lot of this and if the macros were used then some of the changes could
come in quite early
as they would compile out to NOPs for anyone not using the changes.
( and provide an easy target for removal if it eventually doesn't
complete).
I focused with write flexible kernel API and create conception - any
process run with own context. With 'jail2' all processes have
cred->pr_prison defined. As for me it`s allow easy use struct prison as
storage for any context related data such as uid hash, or diskquota
hash, limits info or other. Process count limit and separated uid hash
created as example to use this conception.
Same conception used at my other project - FreeVPS
(http://www.freevps.com/tracker.html).
Where i can see you and Marco work ?
|
Original Marko's page is at http://www.tel.fer.hr/zec/BSD/vimage/, currently
there is http://www.imunes.net with some related info as well. No idea on the
other work. Marko's work is 4-RELEASE bound patch, so it is not directly
usable, but there is some discussion on freebsd-net@ coming regularly about
vrf support on FreeBSD, you can look there as well.
I can only second with support to your work and test anything published
provided I have some time to play with it. (Not guaranteed immediately after
publishing, but nevertheless, I am trying.)
Regards,
Milan
--
No need to mail me directly. Just reply to mailing list, please.
_______________________________________________
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: Wed Jun 07, 2006 7:46 am Post subject:
Re: jail extensions
|
|
|
| Quote: |
I focused with write flexible kernel API and create conception - any
process run with own context. With 'jail2' all processes have
cred->pr_prison defined. As for me it`s allow easy use struct prison as
storage for any context related data such as uid hash, or diskquota
hash, limits info or other. Process count limit and separated uid hash
created as example to use this conception.
Same conception used at my other project - FreeVPS
(http://www.freevps.com/tracker.html).
Where i can see you and Marco work ?
Original Marko's page is at http://www.tel.fer.hr/zec/BSD/vimage/, currently
there is http://www.imunes.net with some related info as well. No idea on the
other work. Marko's work is 4-RELEASE bound patch, so it is not directly
usable, but there is some discussion on freebsd-net@ coming regularly about
vrf support on FreeBSD, you can look there as well.
I can only second with support to your work and test anything published
provided I have some time to play with it. (Not guaranteed immediately after
publishing, but nevertheless, I am trying.)
Regards,
Milan
Okey. I was look into this project over two years ago. |
if you can point me to discussion on freebsd-net@ i`m very interested
with read this before are port network part vimage to jail2.
--
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 |
|
|
Milan Obuch
*nix forums beginner
Joined: 15 Mar 2006
Posts: 3
|
| Posted: Wed Jun 07, 2006 8:11 am Post subject:
Re: jail extensions
|
|
|
On Wednesday 07 June 2006 09:46, Alex Lyashkov wrote:
| Quote: | I focused with write flexible kernel API and create conception - any
process run with own context. With 'jail2' all processes have
cred->pr_prison defined. As for me it`s allow easy use struct prison as
storage for any context related data such as uid hash, or diskquota
hash, limits info or other. Process count limit and separated uid hash
created as example to use this conception.
Same conception used at my other project - FreeVPS
(http://www.freevps.com/tracker.html).
Where i can see you and Marco work ?
Original Marko's page is at http://www.tel.fer.hr/zec/BSD/vimage/,
currently there is http://www.imunes.net with some related info as well.
No idea on the other work. Marko's work is 4-RELEASE bound patch, so it
is not directly usable, but there is some discussion on freebsd-net@
coming regularly about vrf support on FreeBSD, you can look there as
well.
I can only second with support to your work and test anything published
provided I have some time to play with it. (Not guaranteed immediately
after publishing, but nevertheless, I am trying.)
Regards,
Milan
Okey. I was look into this project over two years ago.
if you can point me to discussion on freebsd-net@ i`m very interested
with read this before are port network part vimage to jail2.
|
Two threads recorded in my personal archive -
Subject: multiple routing tables, Date: 21. 03. 2006 10:22 (short)
Subject: vrf support in FreeBSD Date: 09. 05. 2006 06:54 (longer, spans over
two days)
Maybe there were similar threads elsewhere, but I can't remember just now and
I can't search deeper now.
Hope this could be of some interest.
Regards,
Milan
--
No need to mail me directly. Just reply to mailing list, please.
_______________________________________________
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 |
|
|
Robert Watson
*nix forums Guru Wannabe
Joined: 22 Mar 2002
Posts: 218
|
| Posted: Wed Jun 07, 2006 8:59 am Post subject:
Re: jail extensions
|
|
|
On Wed, 7 Jun 2006, Julian Elischer wrote:
| Quote: | I'd like to clarify Alex's point a bit: he wants to know his work is
acceptable by the project and could be merged. It's obvious it's almost
impossible to maintain that outside of the tree.
I'd like to see him merge his project with Marco's . If so then I'd be more
than happy to see this stuff come in once it reaches a certain level of
maturity.
Marco and I have been going over some possible macros that could be used to
help with a lot of this and if the macros were used then some of the changes
could come in quite early as they would compile out to NOPs for anyone not
using the changes. ( and provide an easy target for removal if it eventually
doesn't complete).
|
FYI, Marko was at the FreeBSD developer summit at BSDCan, and has expressed
the intent of updating his patches to 6.x/HEAD, so I think there's definitely
room for collaboration here.
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 |
|
|
John Baldwin
*nix forums Guru Wannabe
Joined: 27 Mar 2002
Posts: 278
|
| Posted: Wed Jun 07, 2006 12:19 pm Post subject:
Re: jail extensions
|
|
|
On Wednesday 07 June 2006 04:59, Robert Watson wrote:
| Quote: |
On Wed, 7 Jun 2006, Julian Elischer wrote:
I'd like to clarify Alex's point a bit: he wants to know his work is
acceptable by the project and could be merged. It's obvious it's almost
impossible to maintain that outside of the tree.
I'd like to see him merge his project with Marco's . If so then I'd be
more
than happy to see this stuff come in once it reaches a certain level of
maturity.
Marco and I have been going over some possible macros that could be used
to
help with a lot of this and if the macros were used then some of the
changes
could come in quite early as they would compile out to NOPs for anyone not
using the changes. ( and provide an easy target for removal if it
eventually
doesn't complete).
FYI, Marko was at the FreeBSD developer summit at BSDCan, and has expressed
the intent of updating his patches to 6.x/HEAD, so I think there's
definitely
room for collaboration here.
|
What did you think about Alex's idea of a 'prison0' to for all "non-jailed"
processes so that lots of things can move into 'struct prison' and not
require as much special casing (though then there would be a different set of
special cases I guess as prison0 would be the only prison that could create
child prisons, etc.?)
--
John Baldwin
_______________________________________________
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: Wed Jun 07, 2006 2:35 pm Post subject:
Re: jail extensions
|
|
|
John Baldwin wrote:
| Quote: | On Wednesday 07 June 2006 04:59, Robert Watson wrote:
On Wed, 7 Jun 2006, Julian Elischer wrote:
I'd like to clarify Alex's point a bit: he wants to know his work is
acceptable by the project and could be merged. It's obvious it's almost
impossible to maintain that outside of the tree.
I'd like to see him merge his project with Marco's . If so then I'd be
more
than happy to see this stuff come in once it reaches a certain level of
maturity.
Marco and I have been going over some possible macros that could be used
to
help with a lot of this and if the macros were used then some of the
changes
could come in quite early as they would compile out to NOPs for anyone not
using the changes. ( and provide an easy target for removal if it
eventually
doesn't complete).
FYI, Marko was at the FreeBSD developer summit at BSDCan, and has expressed
the intent of updating his patches to 6.x/HEAD, so I think there's
definitely
room for collaboration here.
What did you think about Alex's idea of a 'prison0' to for all "non-jailed"
processes so that lots of things can move into 'struct prison' and not
require as much special casing (though then there would be a different set of
special cases I guess as prison0 would be the only prison that could create
child prisons, etc.?)
|
Marco's work is somewhat similar.
All globals related to the network are moved to structures that can be
duplicated.
The base system also uses this structure so that in effect the base
system is just another instance
of the virtual machines. The biggest obstacle is that the 4.x based
version just put everything
into one structure, meaning that it only worked when all the components
effected were
compiled into the kernel. None of them could be implemented as a
loadable kernel module.
This has become much more important in 6.x.
Ther is a way to allow this to work but it would require that we
implement a kernel version of
the idea used for TLS (Thread Local Storage), so that modules being
loaded could be added
to all the existing VMs and new VMs could get instances of all loaded
modules.
(and so that a module could not be unloaded until all VMS have destroyed
their instance
of the related object.)
_______________________________________________
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: Wed Jun 07, 2006 2:56 pm Post subject:
Re: jail extensions
|
|
|
| Quote: |
Marco's work is somewhat similar.
All globals related to the network are moved to structures that can be
duplicated.
The base system also uses this structure so that in effect the base
system is just another instance
of the virtual machines. The biggest obstacle is that the 4.x based
version just put everything
into one structure, meaning that it only worked when all the components
effected were
compiled into the kernel. None of them could be implemented as a
loadable kernel module.
This has become much more important in 6.x.
Ther is a way to allow this to work but it would require that we
implement a kernel version of
the idea used for TLS (Thread Local Storage), so that modules being
loaded could be added
to all the existing VMs and new VMs could get instances of all loaded
modules.
(and so that a module could not be unloaded until all VMS have destroyed
their instance
It`s can be created easy. each module can be full own private data and |
register init/destroy methods, similar SYSINIT macro.
prison will need add array for store pointers to modules data.
yes, it possible need lost more memory - but easy for implementation.
--
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: Wed Jun 07, 2006 3:07 pm Post subject:
Re: jail extensions
|
|
|
Alex Lyashkov wrote:
| Quote: | Marco's work is somewhat similar.
All globals related to the network are moved to structures that can be
duplicated.
The base system also uses this structure so that in effect the base
system is just another instance
of the virtual machines. The biggest obstacle is that the 4.x based
version just put everything
into one structure, meaning that it only worked when all the components
effected were
compiled into the kernel. None of them could be implemented as a
loadable kernel module.
This has become much more important in 6.x.
Ther is a way to allow this to work but it would require that we
implement a kernel version of
the idea used for TLS (Thread Local Storage), so that modules being
loaded could be added
to all the existing VMs and new VMs could get instances of all loaded
modules.
(and so that a module could not be unloaded until all VMS have destroyed
their instance
It`s can be created easy. each module can be full own private data and
register init/destroy methods, similar SYSINIT macro.
prison will need add array for store pointers to modules data.
yes, it possible need lost more memory - but easy for implementation.
|
"Easy" if you are writing something from scratch and you want it to not
be able to be compiled
the old way too.
_______________________________________________
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: Wed Jun 07, 2006 4:08 pm Post subject:
Re: jail extensions
|
|
|
On Wed, Jun 07, 2006 at 08:19:03AM -0400, John Baldwin wrote:
| Quote: | On Wednesday 07 June 2006 04:59, Robert Watson wrote:
On Wed, 7 Jun 2006, Julian Elischer wrote:
I'd like to clarify Alex's point a bit: he wants to know his work is
acceptable by the project and could be merged. It's obvious it's almost
impossible to maintain that outside of the tree.
I'd like to see him merge his project with Marco's . If so then I'd be
more
than happy to see this stuff come in once it reaches a certain level of
maturity.
Marco and I have been going over some possible macros that could be used
to
help with a lot of this and if the macros were used then some of the
changes
could come in quite early as they would compile out to NOPs for anyone not
using the changes. ( and provide an easy target for removal if it
eventually
doesn't complete).
FYI, Marko was at the FreeBSD developer summit at BSDCan, and has expressed
the intent of updating his patches to 6.x/HEAD, so I think there's
definitely
room for collaboration here.
What did you think about Alex's idea of a 'prison0' to for all "non-jailed"
processes so that lots of things can move into 'struct prison' and not
require as much special casing (though then there would be a different set of
special cases I guess as prison0 would be the only prison that could create
child prisons, etc.?)
|
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.
-- Brooks
--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 |
|
| Back to top |
|
|
Brooks Davis
*nix forums addict
Joined: 14 Jun 2002
Posts: 97
|
| Posted: Wed Jun 07, 2006 7:03 pm Post subject:
Re: jail extensions
|
|
|
On Wed, Jun 07, 2006 at 05:56:24PM +0300, Alex Lyashkov wrote:
| Quote: |
Marco's work is somewhat similar.
All globals related to the network are moved to structures that can be
duplicated.
The base system also uses this structure so that in effect the base
system is just another instance
of the virtual machines. The biggest obstacle is that the 4.x based
version just put everything
into one structure, meaning that it only worked when all the components
effected were
compiled into the kernel. None of them could be implemented as a
loadable kernel module.
This has become much more important in 6.x.
Ther is a way to allow this to work but it would require that we
implement a kernel version of
the idea used for TLS (Thread Local Storage), so that modules being
loaded could be added
to all the existing VMs and new VMs could get instances of all loaded
modules.
(and so that a module could not be unloaded until all VMS have destroyed
their instance
It`s can be created easy. each module can be full own private data and
register init/destroy methods, similar SYSINIT macro.
prison will need add array for store pointers to modules data.
yes, it possible need lost more memory - but easy for implementation.
|
Even blowing a page or two per prison probably doesn't matter. It seems
unlikely anyone is going to run large numbers of them on very small
platforms and it's no as if you can run a process that takes less than
3-4 pages anyway.
-- Brooks
--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 |
|
| Back to top |
|
|
Alex Lyashkov
*nix forums beginner
Joined: 06 Jun 2006
Posts: 10
|
| Posted: Thu Jun 08, 2006 9:01 am Post subject:
Re: jail extensions
|
|
|
÷ óÒÄ, 07.06.2006, × 18:07, Julian Elischer ÐÉÛÅÔ:
| Quote: | Alex Lyashkov wrote:
Marco's work is somewhat similar.
All globals related to the network are moved to structures that can be
duplicated.
The base system also uses this structure so that in effect the base
system is just another instance
of the virtual machines. The biggest obstacle is that the 4.x based
version just put everything
into one structure, meaning that it only worked when all the components
effected were
compiled into the kernel. None of them could be implemented as a
loadable kernel module.
This has become much more important in 6.x.
Ther is a way to allow this to work but it would require that we
implement a kernel version of
the idea used for TLS (Thread Local Storage), so that modules being
loaded could be added
to all the existing VMs and new VMs could get instances of all loaded
modules.
(and so that a module could not be unloaded until all VMS have destroyed
their instance
It`s can be created easy. each module can be full own private data and
register init/destroy methods, similar SYSINIT macro.
prison will need add array for store pointers to modules data.
yes, it possible need lost more memory - but easy for implementation.
"Easy" if you are writing something from scratch and you want it to not
be able to be compiled
the old way too.
what you implicit as 'old way' ? I think module will be have 2 way init |
- one for old SYSINIT() who called module_init(&prison0), and additional
JAILINIT() who call module_init(struct prisoin *) for init private data
from new prisons.
for dynamically loaded modules can be 2 ways.
1) if modules loaded - init private data only for (prison0) and wait for
'kldload' from other contexts, where call module_init(struct prisoin *).
At this way me simulate 'kldload' for modules.
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.
--
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 |
|
|
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 |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Wed Dec 03, 2008 10:45 pm | All times are GMT
|
|
Bad Credit Mortgages | Mortgage Calculator | MPAA | Credit Cards UK | Electricity Suppliers
|
|
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
