Naming the "Task containers" framework

Naming the "Task containers" framework

[Paul Menage]

At the mini-summit, and at other times, I've heard the repeated
complaint that having the word "container" in the name of the "task
container" framework leads to ambiguity. And separately from the
complaints, I've seen the awkwardness that people end up with when
they feel they have to distinguish between the "containers" abstract
concept, and "Paul's containers" ...

With the hope/prospect of having the framework merged some time after
the kernel summit, I guess now's a good time to bow to the pressure
and find some compromise that everyone likes, before we actually hit
mainline. (Maybe earlier would have been even better, but ...)

Of the various possible names that have been suggested, there are a
couple that (to me) stand out as good options:

- control groups
- task sets

The former (coined by Eric during a brainstorming session yesterday)
seems to capture the enforcement aspect of the framework (sysadmin can
use it to control the behaviour of processes, processes can't escape
from groups), without suggesting that it can only be used for resource
controllers (as some alternative names such as "resource groups"
imply) and would be a choice that I could be happy with.

Does anyone have strong views on other alternative names (or even the
idea of keeping "task containers")?

Paul

Re: Naming the "Task containers" framework

[Cedric Le Goater]

Paul Menage wrote:

> At the mini-summit, and at other times, I've heard the repeated
> complaint that having the word "container" in the name of the "task
> container" framework leads to ambiguity. And separately from the
> complaints, I've seen the awkwardness that people end up with when
> they feel they have to distinguish between the "containers" abstract
> concept, and "Paul's containers" ...
> 
> With the hope/prospect of having the framework merged some time after
> the kernel summit, I guess now's a good time to bow to the pressure
> and find some compromise that everyone likes, before we actually hit
> mainline. (Maybe earlier would have been even better, but ...)
> 
> Of the various possible names that have been suggested, there are a
> couple that (to me) stand out as good options:
> 
> - control groups
> - task sets

task controllers ?

C. 

> The former (coined by Eric during a brainstorming session yesterday)
> seems to capture the enforcement aspect of the framework (sysadmin can
> use it to control the behaviour of processes, processes can't escape
> from groups), without suggesting that it can only be used for resource
> controllers (as some alternative names such as "resource groups"
> imply) and would be a choice that I could be happy with.
> 
> Does anyone have strong views on other alternative names (or even the
> idea of keeping "task containers")?
> 
> Paul
> _______________________________________________
> Containers mailing list
> Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
> https://lists.linux-foundation.org/mailman/listinfo/containers
> 

Re: Naming the "Task containers" framework

[Paul Menage]

On 9/5/07, Cedric Le Goater <clg-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org> wrote:
> > - control groups
> > - task sets
>
> task controllers ?
>

Hmm. As a name for the framework, this doesn't seem to me quite as
appropriate as "control groups". The framework itself doesn't actually
control groups of tasks, it just provides the partitioning mechanism
and user-space API to make it simple to add such controllers.

Paul

Re: Naming the "Task containers" framework

[Serge E. Hallyn]

Quoting Paul Menage (menage-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org):
> At the mini-summit, and at other times, I've heard the repeated
> complaint that having the word "container" in the name of the "task
> container" framework leads to ambiguity. And separately from the
> complaints, I've seen the awkwardness that people end up with when
> they feel they have to distinguish between the "containers" abstract
> concept, and "Paul's containers" ...
> 
> With the hope/prospect of having the framework merged some time after
> the kernel summit, I guess now's a good time to bow to the pressure
> and find some compromise that everyone likes, before we actually hit
> mainline. (Maybe earlier would have been even better, but ...)
> 
> Of the various possible names that have been suggested, there are a
> couple that (to me) stand out as good options:
> 
> - control groups
> - task sets
> 
> The former (coined by Eric during a brainstorming session yesterday)
> seems to capture the enforcement aspect of the framework (sysadmin can
> use it to control the behaviour of processes, processes can't escape
> from groups), without suggesting that it can only be used for resource
> controllers (as some alternative names such as "resource groups"
> imply) and would be a choice that I could be happy with.
> 
> Does anyone have strong views on other alternative names (or even the
> idea of keeping "task containers")?

Purely subjectively I prefer control groups, but task sets is more
descriptive about the implementation.

So I'd have to vote for task sets.

I like 'task containers', but it really is a pain trying to keep clear
which containers I'm talking about from one sentence to the next.

-serge

Re: Naming the "Task containers" framework

[Paul Menage]

On 9/11/07, Serge E. Hallyn <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:
> Quoting Paul Menage (menage-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org):
> > At the mini-summit, and at other times, I've heard the repeated
> > complaint that having the word "container" in the name of the "task
> > container" framework leads to ambiguity. And separately from the
> > complaints, I've seen the awkwardness that people end up with when
> > they feel they have to distinguish between the "containers" abstract
> > concept, and "Paul's containers" ...
> >
> > With the hope/prospect of having the framework merged some time after
> > the kernel summit, I guess now's a good time to bow to the pressure
> > and find some compromise that everyone likes, before we actually hit
> > mainline. (Maybe earlier would have been even better, but ...)
> >
> > Of the various possible names that have been suggested, there are a
> > couple that (to me) stand out as good options:
> >
> > - control groups
> > - task sets
> >
> > The former (coined by Eric during a brainstorming session yesterday)
> > seems to capture the enforcement aspect of the framework (sysadmin can
> > use it to control the behaviour of processes, processes can't escape
> > from groups), without suggesting that it can only be used for resource
> > controllers (as some alternative names such as "resource groups"
> > imply) and would be a choice that I could be happy with.
> >
> > Does anyone have strong views on other alternative names (or even the
> > idea of keeping "task containers")?
>
> Purely subjectively I prefer control groups, but task sets is more
> descriptive about the implementation.

I described it as "control groups" during the kernel summit
presentation and no-one seemed to object to that name.

As far as I can tell, the general mood seems to be in favour of
"control groups" - no-one else has expressed a preference for "task
sets".

I think it's more important to express the overall intention of the
feature rather than the implementation. Ted T'so (I think) asked at
the summit whether things other than tasks could be first-class
members of control groups - I said that currently they can't, but
people may find interesting ways to conveniently make non-task objects
first-class members in the future (rather than just holding reference
counts the way pages do currently).

>
> So I'd have to vote for task sets.
>
> I like 'task containers', but it really is a pain trying to keep clear
> which containers I'm talking about from one sentence to the next.

Right, enough people have said this to me now, and I've seen the
awkwardness that it entails - I don't want to add a subsystem to the
kernel that's forever referred to as "Paul's containers" :-)

Paul

Re: Naming the "Task containers" framework

[Cedric Le Goater]

Paul Menage wrote:
> On 9/11/07, Serge E. Hallyn <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:
>> Quoting Paul Menage (menage-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org):
>>> At the mini-summit, and at other times, I've heard the repeated
>>> complaint that having the word "container" in the name of the "task
>>> container" framework leads to ambiguity. And separately from the
>>> complaints, I've seen the awkwardness that people end up with when
>>> they feel they have to distinguish between the "containers" abstract
>>> concept, and "Paul's containers" ...
>>>
>>> With the hope/prospect of having the framework merged some time after
>>> the kernel summit, I guess now's a good time to bow to the pressure
>>> and find some compromise that everyone likes, before we actually hit
>>> mainline. (Maybe earlier would have been even better, but ...)
>>>
>>> Of the various possible names that have been suggested, there are a
>>> couple that (to me) stand out as good options:
>>>
>>> - control groups
>>> - task sets
>>>
>>> The former (coined by Eric during a brainstorming session yesterday)
>>> seems to capture the enforcement aspect of the framework (sysadmin can
>>> use it to control the behaviour of processes, processes can't escape
>>> from groups), without suggesting that it can only be used for resource
>>> controllers (as some alternative names such as "resource groups"
>>> imply) and would be a choice that I could be happy with.
>>>
>>> Does anyone have strong views on other alternative names (or even the
>>> idea of keeping "task containers")?
>> Purely subjectively I prefer control groups, but task sets is more
>> descriptive about the implementation.
> 
> I described it as "control groups" during the kernel summit
> presentation and no-one seemed to object to that name.
> 
> As far as I can tell, the general mood seems to be in favour of
> "control groups" - no-one else has expressed a preference for "task
> sets".
>
> I think it's more important to express the overall intention of the
> feature rather than the implementation. Ted T'so (I think) asked at
> the summit whether things other than tasks could be first-class
> members of control groups - I said that currently they can't, but
> people may find interesting ways to conveniently make non-task objects
> first-class members in the future (rather than just holding reference
> counts the way pages do currently).
> 
>> So I'd have to vote for task sets.
>>
>> I like 'task containers', but it really is a pain trying to keep clear
>> which containers I'm talking about from one sentence to the next.
> 
> Right, enough people have said this to me now, and I've seen the
> awkwardness that it entails - I don't want to add a subsystem to the
> kernel that's forever referred to as "Paul's containers" :-)

That's how I've been calling them for a while :)

Now that LWN has announced the name rebrand in the article : 

	http://lwn.net/Articles/249080/

I hope we can close the topic.

C.

Re: Naming the "Task containers" framework

[Serge E. Hallyn]

Quoting Cedric Le Goater (clg-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org):
> Paul Menage wrote:
> > On 9/11/07, Serge E. Hallyn <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:
> >> Quoting Paul Menage (menage-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org):
> >>> At the mini-summit, and at other times, I've heard the repeated
> >>> complaint that having the word "container" in the name of the "task
> >>> container" framework leads to ambiguity. And separately from the
> >>> complaints, I've seen the awkwardness that people end up with when
> >>> they feel they have to distinguish between the "containers" abstract
> >>> concept, and "Paul's containers" ...
> >>>
> >>> With the hope/prospect of having the framework merged some time after
> >>> the kernel summit, I guess now's a good time to bow to the pressure
> >>> and find some compromise that everyone likes, before we actually hit
> >>> mainline. (Maybe earlier would have been even better, but ...)
> >>>
> >>> Of the various possible names that have been suggested, there are a
> >>> couple that (to me) stand out as good options:
> >>>
> >>> - control groups
> >>> - task sets
> >>>
> >>> The former (coined by Eric during a brainstorming session yesterday)
> >>> seems to capture the enforcement aspect of the framework (sysadmin can
> >>> use it to control the behaviour of processes, processes can't escape
> >>> from groups), without suggesting that it can only be used for resource
> >>> controllers (as some alternative names such as "resource groups"
> >>> imply) and would be a choice that I could be happy with.
> >>>
> >>> Does anyone have strong views on other alternative names (or even the
> >>> idea of keeping "task containers")?
> >> Purely subjectively I prefer control groups, but task sets is more
> >> descriptive about the implementation.
> > 
> > I described it as "control groups" during the kernel summit
> > presentation and no-one seemed to object to that name.
> > 
> > As far as I can tell, the general mood seems to be in favour of
> > "control groups" - no-one else has expressed a preference for "task
> > sets".
> >
> > I think it's more important to express the overall intention of the
> > feature rather than the implementation. Ted T'so (I think) asked at
> > the summit whether things other than tasks could be first-class
> > members of control groups - I said that currently they can't, but
> > people may find interesting ways to conveniently make non-task objects
> > first-class members in the future (rather than just holding reference
> > counts the way pages do currently).
> > 
> >> So I'd have to vote for task sets.
> >>
> >> I like 'task containers', but it really is a pain trying to keep clear
> >> which containers I'm talking about from one sentence to the next.
> > 
> > Right, enough people have said this to me now, and I've seen the
> > awkwardness that it entails - I don't want to add a subsystem to the
> > kernel that's forever referred to as "Paul's containers" :-)
> 
> That's how I've been calling them for a while :)

It works pretty well  :)

> Now that LWN has announced the name rebrand in the article : 
> 
> 	http://lwn.net/Articles/249080/
> 
> I hope we can close the topic.

Sure *now* you tell me.  You had to wait until I provided yet one more
example of how my own preferences can be taken as a reliable indicator
of the inverse of the group consensus  :)

-serge