xt file, and it 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
BIO
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 pi
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 thin
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
>> isola
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 cha
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 fun
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 t
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 (ns
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:
>> 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 l
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 cli
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"?
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 im
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 independ
[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, an
16 matches
Mail list logo
