public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <haveblue@us.ibm.com>
To: Sam Vilain <sam@vilain.net>
Cc: linux-kernel@vger.kernel.org,
	Herbert Poetzl <herbert@13thfloor.at>,
	"Eric W.Biederman" <ebiederm@xmission.com>,
	OpenVZ developers list <dev@openvz.org>,
	"Serge E.Hallyn" <serue@us.ibm.com>,
	Andrew Morton <akpm@osdl.org>
Subject: Re: [RFC] [PATCH 0/7] Some basic vserver infrastructure
Date: Tue, 21 Mar 2006 13:32:36 -0800	[thread overview]
Message-ID: <1142976756.10906.200.camel@localhost.localdomain> (raw)
In-Reply-To: <44206B58.5000404@vilain.net>

On Wed, 2006-03-22 at 09:08 +1200, Sam Vilain wrote:
> Dave Hansen wrote:
> >What about going back to the very simple "struct container" on which to
> >build?
> 
> Please read "vx_info" as "container" (or your preferred term).  I
> decided to punt on the naming issue and copy Herbert :-).

My point was that we go back to something simple which we can all
understand and build on.  The code which was just posted is quite
complex.  Although I trust that most of it is needed, the justification
for the complexity simply is not there.

By starting painfully simply, we can build on complexity in bits, and
justify it as we go.

> And also because the acronym "vx" makes the API look nice, at least to
> mine and Herbert's eyes, then when you go to the network virtualisation
> you get "nx_info", etc.  However I'm thinking any of these terms might
> also be right:
> 
>   - "vserver" spelt in full
>   - family
>   - container
>   - jail
>   - task_ns (sort for namespace)
> 
> Perhaps we can get a ruling from core team on this one, as it's
> aesthetics :-).

I was in a meeting with a few coworkers, and we were arguing a bit about
naming.  One person there was a manager-type who didn't have any direct
involvement in the project.  We asked him which naming was more clear.

We need to think a bit like that.  What is more clear to somebody who
has never read the code?  (Hint "vx_" means nothing. :)

> >	http://lkml.org/lkml/2006/2/3/205
> >  
> This patch is simple, but does not handle SMP scalability very well
> (you'll get a lot of cacheline problems when you start actually using
> the container structure; the hashing helps a lot there)

Could you elaborate a bit on this one?  What has cacheline problems?

> and does not provide functions such as looking up a container by ID etc.

We need something so simple that we probably don't even deal with ids.
I believe that Eric claims that we don't really need container _ids_.
For instance, the filesystem namespaces have no ids, and work just fine.

-- Dave


  reply	other threads:[~2006-03-21 21:34 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20060321061333.27638.63963.stgit@localhost.localdomain>
2006-03-21 18:50 ` [RFC] [PATCH 0/7] Some basic vserver infrastructure Dave Hansen
2006-03-21 21:08   ` Sam Vilain
2006-03-21 21:32     ` Dave Hansen [this message]
2006-03-21 23:12       ` Sam Vilain
2006-03-22  5:18         ` Sam Vilain
2006-03-22  7:13         ` Eric W. Biederman
2006-03-23  4:17           ` Sam Vilain
2006-03-24 15:36           ` [Devel] " Kirill Korotaev
2006-03-27 12:45             ` Serge E. Hallyn
2006-03-28  5:28               ` Sam Vilain
2006-03-29 12:07               ` Kirill Korotaev
2006-03-29 13:47                 ` Serge E. Hallyn
2006-03-29 21:30                   ` Sam Vilain
2006-04-19  7:50                     ` Eric W. Biederman
2006-04-19 21:42                       ` Sam Vilain
2006-03-22  6:41   ` Eric W. Biederman
2006-03-23  4:29     ` Sam Vilain
2006-03-23  4:50       ` Andrew Morton
2006-03-24 15:38       ` Kirill Korotaev
2006-03-24 15:37     ` Kirill Korotaev
2006-03-24 20:28       ` Eric W. Biederman
2006-03-24 21:01         ` Herbert Poetzl
2006-03-24 21:13           ` Eric W. Biederman
2006-03-24 21:40             ` Herbert Poetzl
2006-03-24 22:30               ` Eric W. Biederman
2006-03-25 18:37                 ` Eric W. Biederman
     [not found] ` <20060321061333.27638.9112.stgit@localhost.localdomain>
2006-03-21 18:53   ` [RFC] [PATCH 1/7] Add process virtualisation umbrella structure (vx_info) Dave Hansen
2006-03-21 21:52     ` Sam Vilain
2006-03-22  2:02     ` Herbert Poetzl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1142976756.10906.200.camel@localhost.localdomain \
    --to=haveblue@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=dev@openvz.org \
    --cc=ebiederm@xmission.com \
    --cc=herbert@13thfloor.at \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sam@vilain.net \
    --cc=serue@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox