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
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
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
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
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.
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
>>
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
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
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
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
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 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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
[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,
[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
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
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
32 matches
Mail list logo
