On Thu, Mar 22, 2007 at 09:39:09AM -0500, Serge E. Hallyn wrote:
> > What troubles will mounting both cpuset and ns in the same hierarchy
> > cause?
>
> Wow, don't recall the full context here.
Sorry to have come back so late on this :)
> But at least with Paul's container patchset, a subsystem
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
> On Fri, Mar 09, 2007 at 10:50:17AM -0600, Serge E. Hallyn wrote:
> > The nsproxy container subsystem could be said to be that unification.
> > If we really wanted to I suppose we could now always mount the nsproxy
> > subsystem, get rid of
On Fri, Mar 09, 2007 at 10:50:17AM -0600, Serge E. Hallyn wrote:
> The nsproxy container subsystem could be said to be that unification.
> If we really wanted to I suppose we could now always mount the nsproxy
> subsystem, get rid of tsk->nsproxy, and always get thta through it's
> nsproxy
On Fri, Mar 09, 2007 at 10:50:17AM -0600, Serge E. Hallyn wrote:
The nsproxy container subsystem could be said to be that unification.
If we really wanted to I suppose we could now always mount the nsproxy
subsystem, get rid of tsk-nsproxy, and always get thta through it's
nsproxy subsystem
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
On Fri, Mar 09, 2007 at 10:50:17AM -0600, Serge E. Hallyn wrote:
The nsproxy container subsystem could be said to be that unification.
If we really wanted to I suppose we could now always mount the nsproxy
subsystem, get rid of tsk-nsproxy,
On Thu, Mar 22, 2007 at 09:39:09AM -0500, Serge E. Hallyn wrote:
What troubles will mounting both cpuset and ns in the same hierarchy
cause?
Wow, don't recall the full context here.
Sorry to have come back so late on this :)
But at least with Paul's container patchset, a subsystem can
On Mon, Mar 12, 2007 at 07:25:48PM -0700, Paul Menage wrote:
> On 3/12/07, Herbert Poetzl <[EMAIL PROTECTED]> wrote:
> >
> > why? you simply enter that specific space and
> > use the existing mechanisms (netlink, proc, whatever)
> > to retrieve the information with _existing_ tools,
>
> That's
On Mon, Mar 12, 2007 at 07:25:48PM -0700, Paul Menage wrote:
On 3/12/07, Herbert Poetzl [EMAIL PROTECTED] wrote:
why? you simply enter that specific space and
use the existing mechanisms (netlink, proc, whatever)
to retrieve the information with _existing_ tools,
That's assuming that
On 3/12/07, Herbert Poetzl <[EMAIL PROTECTED]> wrote:
why? you simply enter that specific space and
use the existing mechanisms (netlink, proc, whatever)
to retrieve the information with _existing_ tools,
That's assuming that you're using network namespace virtualization,
with each group of
On Tue, Mar 13, 2007 at 12:31:13AM +0100, Herbert Poetzl wrote:
> just means that the current Linux-VServer behaviour
> is a subset of that, no problem there as long as
> it really _is_ a subset :) we always like to provide
> more features in the future, no problem with that :)
Considering the
On Mon, Mar 12, 2007 at 09:50:45PM +0530, Srivatsa Vaddagiri wrote:
> On Mon, Mar 12, 2007 at 10:56:43AM -0500, Serge E. Hallyn wrote:
> > What's wrong with that?
>
> I had been asking around on "what is the fundamental unit of res mgmt
> for vservers" and the answer I got (from Herbert) was "all
On Mon, Mar 12, 2007 at 03:00:25AM -0700, Paul Menage wrote:
> On 3/11/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> >
> > My current understanding of Paul Menage's container patch is that it is
> > a useful improvement for some of the metered classes - those that could
> > make good use of a file
Srivatsa Vaddagiri wrote:
> On Mon, Mar 12, 2007 at 10:56:43AM -0500, Serge E. Hallyn wrote:
>
>> What's wrong with that?
>>
>
> I had been asking around on "what is the fundamental unit of res mgmt
> for vservers" and the answer I got (from Herbert) was "all tasks that are
> in the same
vatsa wrote:
> This assumes that you can see the global vfs namespace right?
>
> What if you are inside a container/vserver which restricts your vfs
> namespace? i.e /dev/cpusets seen from one container is not same as what
> is seen from another container .
Well, yes. But that restriction on
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
> On Mon, Mar 12, 2007 at 10:56:43AM -0500, Serge E. Hallyn wrote:
> > What's wrong with that?
>
> I had been asking around on "what is the fundamental unit of res mgmt
> for vservers" and the answer I got (from Herbert) was "all tasks that are
> in
On Mon, Mar 12, 2007 at 10:56:43AM -0500, Serge E. Hallyn wrote:
> What's wrong with that?
I had been asking around on "what is the fundamental unit of res mgmt
for vservers" and the answer I got (from Herbert) was "all tasks that are
in the same pid namespace". From what you are saying above, it
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
> On Fri, Mar 09, 2007 at 02:09:35PM -0800, Paul Menage wrote:
> > > 3. This next leads me to think that 'tasks' file in each directory doesnt
> > > make
> > >sense for containers. In fact it can lend itself to error situations
> > > (by
> > >
On Mon, Mar 12, 2007 at 07:31:48PM +0530, Srivatsa Vaddagiri wrote:
> not so. This in-fact lets vservers and containers to work with each
> other. So:
s/containers/cpusets
--
Regards,
vatsa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Fri, Mar 09, 2007 at 02:09:35PM -0800, Paul Menage wrote:
> > 3. This next leads me to think that 'tasks' file in each directory doesnt
> > make
> >sense for containers. In fact it can lend itself to error situations (by
> >administrator/script mistake) when some tasks of a container
On Wed, Mar 07, 2007 at 03:59:19PM -0600, Serge E. Hallyn wrote:
> > containers patches uses just a single pointer in the task_struct, and
> > all tasks in the same set of containers (across all hierarchies) will
> > share a single container_group object, which holds the actual pointers
> > to
On Fri, Mar 09, 2007 at 02:06:03PM -0800, Paul Jackson wrote:
> > if you create a 'resource container' to limit the
> > usage of a set of resources for the processes
> > belonging to this container, it would be kind of
> > defeating the purpose, if you'd allow the processes
> > to manipulate
On 3/11/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
My current understanding of Paul Menage's container patch is that it is
a useful improvement for some of the metered classes - those that could
make good use of a file system like hierarchy for their interface.
It probably doesn't benefit all
Allow me to annotate your nice summary. A lot of this is elaborating on
what you are saying; and I think where we disagree, the differences are
not important.
Paul Jackson wrote:
> We have actors, known as threads, tasks or processes, which use things,
> which are instances of such classes of
Allow me to annotate your nice summary. A lot of this is elaborating on
what you are saying; and I think where we disagree, the differences are
not important.
Paul Jackson wrote:
We have actors, known as threads, tasks or processes, which use things,
which are instances of such classes of
On 3/11/07, Paul Jackson [EMAIL PROTECTED] wrote:
My current understanding of Paul Menage's container patch is that it is
a useful improvement for some of the metered classes - those that could
make good use of a file system like hierarchy for their interface.
It probably doesn't benefit all
On Fri, Mar 09, 2007 at 02:06:03PM -0800, Paul Jackson wrote:
if you create a 'resource container' to limit the
usage of a set of resources for the processes
belonging to this container, it would be kind of
defeating the purpose, if you'd allow the processes
to manipulate their
On Wed, Mar 07, 2007 at 03:59:19PM -0600, Serge E. Hallyn wrote:
containers patches uses just a single pointer in the task_struct, and
all tasks in the same set of containers (across all hierarchies) will
share a single container_group object, which holds the actual pointers
to container
On Fri, Mar 09, 2007 at 02:09:35PM -0800, Paul Menage wrote:
3. This next leads me to think that 'tasks' file in each directory doesnt
make
sense for containers. In fact it can lend itself to error situations (by
administrator/script mistake) when some tasks of a container are in
On Mon, Mar 12, 2007 at 07:31:48PM +0530, Srivatsa Vaddagiri wrote:
not so. This in-fact lets vservers and containers to work with each
other. So:
s/containers/cpusets
--
Regards,
vatsa
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
On Fri, Mar 09, 2007 at 02:09:35PM -0800, Paul Menage wrote:
3. This next leads me to think that 'tasks' file in each directory doesnt
make
sense for containers. In fact it can lend itself to error situations
(by
On Mon, Mar 12, 2007 at 10:56:43AM -0500, Serge E. Hallyn wrote:
What's wrong with that?
I had been asking around on what is the fundamental unit of res mgmt
for vservers and the answer I got (from Herbert) was all tasks that are
in the same pid namespace. From what you are saying above, it
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
On Mon, Mar 12, 2007 at 10:56:43AM -0500, Serge E. Hallyn wrote:
What's wrong with that?
I had been asking around on what is the fundamental unit of res mgmt
for vservers and the answer I got (from Herbert) was all tasks that are
in the same
vatsa wrote:
This assumes that you can see the global vfs namespace right?
What if you are inside a container/vserver which restricts your vfs
namespace? i.e /dev/cpusets seen from one container is not same as what
is seen from another container .
Well, yes. But that restriction on the
Srivatsa Vaddagiri wrote:
On Mon, Mar 12, 2007 at 10:56:43AM -0500, Serge E. Hallyn wrote:
What's wrong with that?
I had been asking around on what is the fundamental unit of res mgmt
for vservers and the answer I got (from Herbert) was all tasks that are
in the same pid namespace.
On Mon, Mar 12, 2007 at 03:00:25AM -0700, Paul Menage wrote:
On 3/11/07, Paul Jackson [EMAIL PROTECTED] wrote:
My current understanding of Paul Menage's container patch is that it is
a useful improvement for some of the metered classes - those that could
make good use of a file system
On Mon, Mar 12, 2007 at 09:50:45PM +0530, Srivatsa Vaddagiri wrote:
On Mon, Mar 12, 2007 at 10:56:43AM -0500, Serge E. Hallyn wrote:
What's wrong with that?
I had been asking around on what is the fundamental unit of res mgmt
for vservers and the answer I got (from Herbert) was all tasks
On Tue, Mar 13, 2007 at 12:31:13AM +0100, Herbert Poetzl wrote:
just means that the current Linux-VServer behaviour
is a subset of that, no problem there as long as
it really _is_ a subset :) we always like to provide
more features in the future, no problem with that :)
Considering the
On 3/12/07, Herbert Poetzl [EMAIL PROTECTED] wrote:
why? you simply enter that specific space and
use the existing mechanisms (netlink, proc, whatever)
to retrieve the information with _existing_ tools,
That's assuming that you're using network namespace virtualization,
with each group of
Sam, responding to Herbert:
> > from my personal PoV the following would be fine:
> >
> > spaces (for the various 'spaces')
> >...
> > container (for resource accounting/limits)
> >...
>
> I like these a lot ...
Hmmm ... ok ...
Let me see if I understand this.
We have actors, known
Sam, responding to Herbert:
from my personal PoV the following would be fine:
spaces (for the various 'spaces')
...
container (for resource accounting/limits)
...
I like these a lot ...
Hmmm ... ok ...
Let me see if I understand this.
We have actors, known as threads,
Herbert Poetzl wrote:
> On Wed, Mar 07, 2007 at 11:44:58PM -0700, Eric W. Biederman wrote:
>
>> I really don't much care as long as we don't start redefining
>> container as something else. I think the IBM guys took it from
>> solaris originally which seems to define a zone as a set of
>>
Herbert Poetzl wrote:
On Wed, Mar 07, 2007 at 11:44:58PM -0700, Eric W. Biederman wrote:
I really don't much care as long as we don't start redefining
container as something else. I think the IBM guys took it from
solaris originally which seems to define a zone as a set of
isolated
On Sat, Mar 10, 2007 at 07:32:20AM +0530, Srivatsa Vaddagiri wrote:
> Ok, let me see if I can convey what I had in mind better:
>
> uts_ns pid_ns ipc_ns
> \|/
> ---
> | nsproxy|
>
>
> the emphasis here is on 'from inside' which basically
> boils down to the following:
>
> if you create a 'resource container' to limit the
> usage of a set of resources for the processes
> belonging to this container, it would be kind of
> defeating the purpose, if you'd allow the processes
On Fri, Mar 09, 2007 at 11:49:08PM +0530, Srivatsa Vaddagiri wrote:
> On Fri, Mar 09, 2007 at 01:53:57AM +0100, Herbert Poetzl wrote:
>>> The real trick is that I believe these groupings are designed to
>>> be something you can setup on login and then not be able to switch
>>> out of. Which means
Herbert wrote (and vatsa quoted):
> precisely, once you are inside a resource container, you
> must not have the ability to modify its limits, and to
> some degree, you should not know about the actual available
> resources, but only about the artificial limits
Not necessarily. Depending on the
On Fri, Mar 09, 2007 at 01:53:57AM +0100, Herbert Poetzl wrote:
> > The real trick is that I believe these groupings are designed to
> > be something you can setup on login and then not be able to switch
> > out of. Which means we can't use sessions and process groups as the
> > grouping entities
Quoting Paul Menage ([EMAIL PROTECTED]):
> On 3/7/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
> >
> >Ok, they share this characteristic with namespaces: that they group
> >processes.
Namespaces have a side effect of grouping processes, but a namespace is
not defined by 'grouping proceses.' A
On Fri, Mar 09, 2007 at 10:04:30PM +0530, Srivatsa Vaddagiri wrote:
> 2. Regarding space savings, if 100 tasks are in a container (I dont know
>what is a typical number) -and- lets say that all tasks are to share
>the same resource allocation (which seems to be natural), then having
>a
On Fri, Mar 09, 2007 at 10:04:30PM +0530, Srivatsa Vaddagiri wrote:
2. Regarding space savings, if 100 tasks are in a container (I dont know
what is a typical number) -and- lets say that all tasks are to share
the same resource allocation (which seems to be natural), then having
a
Quoting Paul Menage ([EMAIL PROTECTED]):
On 3/7/07, Sam Vilain [EMAIL PROTECTED] wrote:
Ok, they share this characteristic with namespaces: that they group
processes.
Namespaces have a side effect of grouping processes, but a namespace is
not defined by 'grouping proceses.' A container is,
On Fri, Mar 09, 2007 at 01:53:57AM +0100, Herbert Poetzl wrote:
The real trick is that I believe these groupings are designed to
be something you can setup on login and then not be able to switch
out of. Which means we can't use sessions and process groups as the
grouping entities as those
Herbert wrote (and vatsa quoted):
precisely, once you are inside a resource container, you
must not have the ability to modify its limits, and to
some degree, you should not know about the actual available
resources, but only about the artificial limits
Not necessarily. Depending on the
On Fri, Mar 09, 2007 at 11:49:08PM +0530, Srivatsa Vaddagiri wrote:
On Fri, Mar 09, 2007 at 01:53:57AM +0100, Herbert Poetzl wrote:
The real trick is that I believe these groupings are designed to
be something you can setup on login and then not be able to switch
out of. Which means we can't
the emphasis here is on 'from inside' which basically
boils down to the following:
if you create a 'resource container' to limit the
usage of a set of resources for the processes
belonging to this container, it would be kind of
defeating the purpose, if you'd allow the processes
to
On Sat, Mar 10, 2007 at 07:32:20AM +0530, Srivatsa Vaddagiri wrote:
Ok, let me see if I can convey what I had in mind better:
uts_ns pid_ns ipc_ns
\|/
---
| nsproxy|
Matt wrote:
> It's like that Star Trek episode ... except we can't agree on the name
Usually, when there is this much heat and smoke over a name, there is
really an underlying disagreement or misunderstanding over the meaning
of something.
The name becomes the proxy for meaning ;).
--
> The real trick is that I believe these groupings are designed to be something
> you can setup on login and then not be able to switch out of. Which means
> we can't use sessions and process groups as the grouping entities as those
> have different semantics.
Not always on login. For big
On Wed, Mar 07, 2007 at 11:44:58PM -0700, Eric W. Biederman wrote:
> Matt Helsley <[EMAIL PROTECTED]> writes:
>
> > On Thu, 2007-03-08 at 16:32 +-1300, Sam Vilain wrote:
> >
> > +ADw-snip+AD4
> >
> > +AD4 Kirill, 06032418:36+-03:
> > +AD4 +AD4 I propose to use +ACI-namespace+ACI naming.
> > +AD4
On Wed, Mar 07, 2007 at 05:35:58PM -0800, Paul Menage wrote:
> On 3/7/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> Pretty much. For most of the other cases I think we are safe
>> referring to them as resource controls or resource limits. I know
>> that roughly covers what cpusets and
On Wed, Mar 07, 2007 at 06:32:10PM -0700, Eric W. Biederman wrote:
> "Paul Menage" <[EMAIL PROTECTED]> writes:
>
>> On 3/7/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
>>> But "namespace" has well-established historical semantics too - a way
>>> of changing the mappings of local * to global objects.
On 3/7/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
Ok, they share this characteristic with namespaces: that they group
processes. So, they conceptually hang off task_struct. But we put them
on ns_proxy because we've got this vague notion that things might be
better that way.
Remember that I'm
On Wed, Mar 07, 2007 at 06:32:10PM -0700, Eric W. Biederman wrote:
Paul Menage [EMAIL PROTECTED] writes:
On 3/7/07, Sam Vilain [EMAIL PROTECTED] wrote:
But namespace has well-established historical semantics too - a way
of changing the mappings of local * to global objects. This
accurately
On Wed, Mar 07, 2007 at 05:35:58PM -0800, Paul Menage wrote:
On 3/7/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
Pretty much. For most of the other cases I think we are safe
referring to them as resource controls or resource limits. I know
that roughly covers what cpusets and beancounters
On Wed, Mar 07, 2007 at 11:44:58PM -0700, Eric W. Biederman wrote:
Matt Helsley [EMAIL PROTECTED] writes:
On Thu, 2007-03-08 at 16:32 +-1300, Sam Vilain wrote:
+ADw-snip+AD4
+AD4 Kirill, 06032418:36+-03:
+AD4 +AD4 I propose to use +ACI-namespace+ACI naming.
+AD4 +AD4 1. This is
The real trick is that I believe these groupings are designed to be something
you can setup on login and then not be able to switch out of. Which means
we can't use sessions and process groups as the grouping entities as those
have different semantics.
Not always on login. For big
Matt wrote:
It's like that Star Trek episode ... except we can't agree on the name
Usually, when there is this much heat and smoke over a name, there is
really an underlying disagreement or misunderstanding over the meaning
of something.
The name becomes the proxy for meaning ;).
--
On 3/7/07, Sam Vilain [EMAIL PROTECTED] wrote:
Ok, they share this characteristic with namespaces: that they group
processes. So, they conceptually hang off task_struct. But we put them
on ns_proxy because we've got this vague notion that things might be
better that way.
Remember that I'm
Matt Helsley <[EMAIL PROTECTED]> writes:
> On Thu, 2007-03-08 at 16:32 +-1300, Sam Vilain wrote:
>
> +ADw-snip+AD4
>
> +AD4 Kirill, 06032418:36+-03:
> +AD4 +AD4 I propose to use +ACI-namespace+ACI naming.
> +AD4 +AD4 1. This is already used in fs.
> +AD4 +AD4 2. This is what IMHO suites at least
Sam Vilain <[EMAIL PROTECTED]> writes:
> And do we bother changing IPC namespaces or let that one slide?
ipc namespaces works (if you worry about tiny details like we put
the resource limits for the sysv ipc objects inside the namespace).
Probably the most instructive example of this is that
On Thu, 2007-03-08 at 16:32 +1300, Sam Vilain wrote:
> Kirill, 06032418:36+03:
> > I propose to use "namespace" naming.
> > 1. This is already used in fs.
> > 2. This is what IMHO suites at least OpenVZ/Eric
> > 3. it has good acronym "ns".
>
> Right. So, now I'll also throw into the mix:
>
Paul Menage wrote:
> I made sure to check [...]wikipedia.org[...] when this argument started ...
> :-)
>
Wikipedia?! That's not a referen[...]
oh bugger it. I've vented enough today and we're on the same page now I
think.
>> This is the classic terminology problem between substance and
On 3/7/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
Sorry, I didn't realise I was talking with somebody qualified enough to
speak on behalf of the Generally Established Principles of Computer Science.
I made sure to check
http://en.wikipedia.org/wiki/Namespace
Paul Menage wrote:
> Sorry, I think this statement is wrong, by the generally established
> meaning of the term namespace in computer science.
>
Sorry, I didn't realise I was talking with somebody qualified enough to
speak on behalf of the Generally Established Principles of Computer Science.
"Paul Menage" <[EMAIL PROTECTED]> writes:
> On 3/7/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> The real trick is that I believe these groupings are designed to be something
>> you can setup on login and then not be able to switch out of.
>
> That's going to to be the case for most
On 3/7/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
Pretty much. For most of the other cases I think we are safe referring
to them as resource controls or resource limits.I know that roughly covers
what cpusets and beancounters and ckrm currently do.
Plus resource monitoring (which
"Paul Menage" <[EMAIL PROTECTED]> writes:
> On 3/7/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
>> But "namespace" has well-established historical semantics too - a way
>> of changing the mappings of local * to global objects. This
>> accurately describes things liek resource controllers, cpusets,
On 3/7/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
But "namespace" has well-established historical semantics too - a way
of changing the mappings of local * to global objects. This
accurately describes things liek resource controllers, cpusets, resource
monitoring, etc.
Sorry, I think this
On Wed, Mar 07, 2007 at 09:29:12AM -0800, Paul Menage wrote:
> That seems bad. With the current way you're doing it, if I mount
> hierarchies A and B on /mnt/A and /mnt/B, then initially all tasks are
> in /mnt/A/tasks and /mnt/B/tasks. If I then create /mnt/A/foo and move
> a process into it,
On Wed, Mar 07, 2007 at 09:29:12AM -0800, Paul Menage wrote:
That seems bad. With the current way you're doing it, if I mount
hierarchies A and B on /mnt/A and /mnt/B, then initially all tasks are
in /mnt/A/tasks and /mnt/B/tasks. If I then create /mnt/A/foo and move
a process into it, that
On 3/7/07, Sam Vilain [EMAIL PROTECTED] wrote:
But namespace has well-established historical semantics too - a way
of changing the mappings of local * to global objects. This
accurately describes things liek resource controllers, cpusets, resource
monitoring, etc.
Sorry, I think this statement
Paul Menage [EMAIL PROTECTED] writes:
On 3/7/07, Sam Vilain [EMAIL PROTECTED] wrote:
But namespace has well-established historical semantics too - a way
of changing the mappings of local * to global objects. This
accurately describes things liek resource controllers, cpusets, resource
On 3/7/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
Pretty much. For most of the other cases I think we are safe referring
to them as resource controls or resource limits.I know that roughly covers
what cpusets and beancounters and ckrm currently do.
Plus resource monitoring (which may
Paul Menage [EMAIL PROTECTED] writes:
On 3/7/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
The real trick is that I believe these groupings are designed to be something
you can setup on login and then not be able to switch out of.
That's going to to be the case for most resource controllers
Paul Menage wrote:
Sorry, I think this statement is wrong, by the generally established
meaning of the term namespace in computer science.
Sorry, I didn't realise I was talking with somebody qualified enough to
speak on behalf of the Generally Established Principles of Computer Science.
On 3/7/07, Sam Vilain [EMAIL PROTECTED] wrote:
Sorry, I didn't realise I was talking with somebody qualified enough to
speak on behalf of the Generally Established Principles of Computer Science.
I made sure to check
http://en.wikipedia.org/wiki/Namespace
Paul Menage wrote:
I made sure to check [...]wikipedia.org[...] when this argument started ...
:-)
Wikipedia?! That's not a referen[...]
oh bugger it. I've vented enough today and we're on the same page now I
think.
This is the classic terminology problem between substance and
On Thu, 2007-03-08 at 16:32 +1300, Sam Vilain wrote:
snip
Kirill, 06032418:36+03:
I propose to use namespace naming.
1. This is already used in fs.
2. This is what IMHO suites at least OpenVZ/Eric
3. it has good acronym ns.
Right. So, now I'll also throw into the mix:
-
Sam Vilain [EMAIL PROTECTED] writes:
And do we bother changing IPC namespaces or let that one slide?
ipc namespaces works (if you worry about tiny details like we put
the resource limits for the sysv ipc objects inside the namespace).
Probably the most instructive example of this is that you
Matt Helsley [EMAIL PROTECTED] writes:
On Thu, 2007-03-08 at 16:32 +-1300, Sam Vilain wrote:
+ADw-snip+AD4
+AD4 Kirill, 06032418:36+-03:
+AD4 +AD4 I propose to use +ACI-namespace+ACI naming.
+AD4 +AD4 1. This is already used in fs.
+AD4 +AD4 2. This is what IMHO suites at least
On Tue, Mar 06, 2007 at 02:28:39PM +0100, Herbert Poetzl wrote:
> groups like Memory, Disk Space, Sockets might make
> sense though, although we never had a single request
> for any overlapping in the resource management (while
> we have quite a few users of overlapping Network spaces)
If we have
On Tue, Mar 06, 2007 at 04:09:40PM +0530, Srivatsa Vaddagiri wrote:
> On Mon, Mar 05, 2007 at 07:39:37PM +0100, Herbert Poetzl wrote:
> > > Thats why nsproxy has pointers to resource control objects, rather
> > > than embedding resource control information in nsproxy itself.
> >
> > which makes
On Mon, Mar 05, 2007 at 07:39:37PM +0100, Herbert Poetzl wrote:
> > Thats why nsproxy has pointers to resource control objects, rather
> > than embedding resource control information in nsproxy itself.
>
> which makes it a (name)space, no?
I tend to agree, yes!
> > This will let different
On Mon, Mar 05, 2007 at 07:39:37PM +0100, Herbert Poetzl wrote:
Thats why nsproxy has pointers to resource control objects, rather
than embedding resource control information in nsproxy itself.
which makes it a (name)space, no?
I tend to agree, yes!
This will let different nsproxy
On Tue, Mar 06, 2007 at 04:09:40PM +0530, Srivatsa Vaddagiri wrote:
On Mon, Mar 05, 2007 at 07:39:37PM +0100, Herbert Poetzl wrote:
Thats why nsproxy has pointers to resource control objects, rather
than embedding resource control information in nsproxy itself.
which makes it a
On Tue, Mar 06, 2007 at 02:28:39PM +0100, Herbert Poetzl wrote:
groups like Memory, Disk Space, Sockets might make
sense though, although we never had a single request
for any overlapping in the resource management (while
we have quite a few users of overlapping Network spaces)
If we have to
On Mon, Mar 05, 2007 at 11:04:01PM +0530, Srivatsa Vaddagiri wrote:
> On Sat, Mar 03, 2007 at 06:32:44PM +0100, Herbert Poetzl wrote:
> > > Yes, perhaps this overloads nsproxy more than what it was intended for.
> > > But, then if we have to to support resource management of each
> > >
On Sat, Mar 03, 2007 at 06:32:44PM +0100, Herbert Poetzl wrote:
> > Yes, perhaps this overloads nsproxy more than what it was intended for.
> > But, then if we have to to support resource management of each
> > container/vserver (or whatever group is represented by nsproxy),
> > then nsproxy seems
On Sat, Mar 03, 2007 at 06:32:44PM +0100, Herbert Poetzl wrote:
Yes, perhaps this overloads nsproxy more than what it was intended for.
But, then if we have to to support resource management of each
container/vserver (or whatever group is represented by nsproxy),
then nsproxy seems the
On Mon, Mar 05, 2007 at 11:04:01PM +0530, Srivatsa Vaddagiri wrote:
On Sat, Mar 03, 2007 at 06:32:44PM +0100, Herbert Poetzl wrote:
Yes, perhaps this overloads nsproxy more than what it was intended for.
But, then if we have to to support resource management of each
container/vserver (or
100 matches
Mail list logo
