Serial console and the Sun X4100M2 ILOM

2007-11-07 Thread Sam Vilain
seems that while boot is in progress the "system driver" is active vs the "modular driver". However, I'm not sure why there is a change of driver at that point; I didn't ask for it. I'm coming to the conclusion that the serial console redirection in the BIOS is broken somehow, anyone ha

Serial console and the Sun X4100M2 ILOM

2007-11-07 Thread Sam Vilain
there is a change of driver at that point; I didn't ask for it. I'm coming to the conclusion that the serial console redirection in the BIOS is broken somehow, anyone have any ideas on tracking this down further? -- Sam Vilain, Chief Yak Shaver, Catalyst IT (NZ) Ltd. phone: +64 4 499 2267PGP

Re: [ckrm-tech] [PATCH 0/2] resource control file system - aka containers on top of nsproxy!

2007-03-12 Thread Sam Vilain
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

Re: [ckrm-tech] [PATCH 0/2] resource control file system - aka containers on top of nsproxy!

2007-03-12 Thread Sam Vilain
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

Re: [ckrm-tech] [PATCH 0/2] resource control file system - aka containers on top of nsproxy!

2007-03-12 Thread Sam Vilain
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

Re: [ckrm-tech] [PATCH 0/2] resource control file system - aka containers on top of nsproxy!

2007-03-12 Thread Sam Vilain
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.

Re: [ckrm-tech] [PATCH 0/2] resource control file system - aka containers on top of nsproxy!

2007-03-10 Thread Sam Vilain
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 >>

Re: [PATCH 0/2] resource control file system - aka containers on top of nsproxy!

2007-03-10 Thread Sam Vilain
Paul Jackson 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. >> > > No! > > Cpusets don't rename or

Re: [PATCH 0/2] resource control file system - aka containers on top of nsproxy!

2007-03-10 Thread Sam Vilain
Paul Jackson 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. No! Cpusets don't rename or change the mapping

Re: [ckrm-tech] [PATCH 0/2] resource control file system - aka containers on top of nsproxy!

2007-03-10 Thread Sam Vilain
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

Re: [ckrm-tech] [PATCH 0/2] resource control file system - aka containers on top of nsproxy!

2007-03-07 Thread Sam Vilain
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

Re: [ckrm-tech] [PATCH 0/2] resource control file system - aka containers on top of nsproxy!

2007-03-07 Thread Sam Vilain
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.

Re: [PATCH 0/2] resource control file system - aka containers on top of nsproxy!

2007-03-07 Thread Sam Vilain
Paul Menage wrote: > But "namespace" has well-established historical semantics too - a way > of changing the mappings of local names to global objects. This > doesn't describe things liek resource controllers, cpusets, resource > monitoring, etc. > > Trying to extend the well-known term namespace

Re: [PATCH 0/2] resource control file system - aka containers on top of nsproxy!

2007-03-07 Thread Sam Vilain
Srivatsa Vaddagiri wrote: > container structure in your patches provides for these things: > > a. A way to group tasks > b. A way to maintain several hierarchies of such groups > > If you consider just a. then I agree that container abstraction is > redundant, esp for vserver resource control

Re: [PATCH 0/2] resource control file system - aka containers on top of nsproxy!

2007-03-07 Thread Sam Vilain
Paul Menage wrote: >> In the namespace world when we say container we mean roughly at the level >> of nsproxy and container_group. >> > So you're saying that a task can only be in a single system-wide container. > Nope, we didn't make the mistake of nailing down what a "container" was too

Re: [PATCH 0/2] resource control file system - aka containers on top of nsproxy!

2007-03-07 Thread Sam Vilain
Paul Menage wrote: In the namespace world when we say container we mean roughly at the level of nsproxy and container_group. So you're saying that a task can only be in a single system-wide container. Nope, we didn't make the mistake of nailing down what a container was too far

Re: [PATCH 0/2] resource control file system - aka containers on top of nsproxy!

2007-03-07 Thread Sam Vilain
Srivatsa Vaddagiri wrote: container structure in your patches provides for these things: a. A way to group tasks b. A way to maintain several hierarchies of such groups If you consider just a. then I agree that container abstraction is redundant, esp for vserver resource control (nsproxy

Re: [PATCH 0/2] resource control file system - aka containers on top of nsproxy!

2007-03-07 Thread Sam Vilain
Paul Menage wrote: But namespace has well-established historical semantics too - a way of changing the mappings of local names to global objects. This doesn't describe things liek resource controllers, cpusets, resource monitoring, etc. Trying to extend the well-known term namespace to refer

Re: [ckrm-tech] [PATCH 0/2] resource control file system - aka containers on top of nsproxy!

2007-03-07 Thread Sam Vilain
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.

Re: [ckrm-tech] [PATCH 0/2] resource control file system - aka containers on top of nsproxy!

2007-03-07 Thread Sam Vilain
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

Re: [PATCH 0/7] containers (V7): Generic Process Containers

2007-02-20 Thread Sam Vilain
Paul Menage wrote: >> No. A reverse mapping is not needed and is not interesting. >> > ... to you. > You're missing the point of Eric's next sentence. If you can achieve everything you need to achieve and get all the information you are after without it, then it is uninteresting. >> As

Re: [PATCH 0/7] containers (V7): Generic Process Containers

2007-02-20 Thread Sam Vilain
Paul Menage wrote: >> The term "segregated group of processes" is too vague. Segregated for >> what? What is the kernel supposed to do with this information? >> > The generic part of the kernel just keeps track of the fact that > they're segregated (and their children, etc). > > It's the

Re: [PATCH 0/7] containers (V7): Generic Process Containers

2007-02-20 Thread Sam Vilain
Paul Menage wrote: >> Using the container name is bad and it led to this stupid argument. >> >> The fundamental unit of what we have merged into the kernel is the >> namespace. The aggregate of all namespaces and everything is the >> container. >> > What are you defining here as

Re: [PATCH 0/7] containers (V7): Generic Process Containers

2007-02-20 Thread Sam Vilain
Paul Menage wrote: Using the container name is bad and it led to this stupid argument. The fundamental unit of what we have merged into the kernel is the namespace. The aggregate of all namespaces and everything is the container. What are you defining here as everything? If you mean

Re: [PATCH 0/7] containers (V7): Generic Process Containers

2007-02-20 Thread Sam Vilain
Paul Menage wrote: The term segregated group of processes is too vague. Segregated for what? What is the kernel supposed to do with this information? The generic part of the kernel just keeps track of the fact that they're segregated (and their children, etc). It's the clients of

Re: [PATCH 0/7] containers (V7): Generic Process Containers

2007-02-20 Thread Sam Vilain
Paul Menage wrote: No. A reverse mapping is not needed and is not interesting. ... to you. You're missing the point of Eric's next sentence. If you can achieve everything you need to achieve and get all the information you are after without it, then it is uninteresting. As long as

Re: [ckrm-tech] [PATCH 0/7] containers (V7): Generic Process Containers

2007-02-12 Thread Sam Vilain
Paul Menage wrote: >> Ask yourself this - what do you need the container structure for so >> badly, that virtualising the individual resources does not provide for? >> > Primarily, that otherwise every module that wants to affect/monitor > behaviour of a group of associated processes has to

Re: [PATCH 0/7] containers (V7): Generic Process Containers

2007-02-12 Thread Sam Vilain
Paul Menage wrote: >> I know I'm a bit out of touch, but AIUI the NSProxy *is* the container. >> We decided a long time ago that a container was basically just a set of >> namespaces, which includes all of the subsystems you mention. >> > You may have done that, but the CKRM/ResGroups

Re: [PATCH 0/7] containers (V7): Generic Process Containers

2007-02-12 Thread Sam Vilain
[EMAIL PROTECTED] wrote: > Generic Process Containers > -- > > There have recently been various proposals floating around for > resource management/accounting and other task grouping subsystems in > the kernel, including ResGroups, User BeanCounters, NSProxy > containers,

Re: [PATCH 0/7] containers (V7): Generic Process Containers

2007-02-12 Thread Sam Vilain
[EMAIL PROTECTED] wrote: Generic Process Containers -- There have recently been various proposals floating around for resource management/accounting and other task grouping subsystems in the kernel, including ResGroups, User BeanCounters, NSProxy containers, and

Re: [PATCH 0/7] containers (V7): Generic Process Containers

2007-02-12 Thread Sam Vilain
Paul Menage wrote: I know I'm a bit out of touch, but AIUI the NSProxy *is* the container. We decided a long time ago that a container was basically just a set of namespaces, which includes all of the subsystems you mention. You may have done that, but the CKRM/ResGroups independently

Re: [ckrm-tech] [PATCH 0/7] containers (V7): Generic Process Containers

2007-02-12 Thread Sam Vilain
Paul Menage wrote: Ask yourself this - what do you need the container structure for so badly, that virtualising the individual resources does not provide for? Primarily, that otherwise every module that wants to affect/monitor behaviour of a group of associated processes has to implement