All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sam Vilain <sam@vilain.net>
To: Dave Hansen <haveblue@us.ibm.com>
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: Wed, 22 Mar 2006 09:08:40 +1200	[thread overview]
Message-ID: <44206B58.5000404@vilain.net> (raw)
In-Reply-To: <1142967011.10906.185.camel@localhost.localdomain>

Dave Hansen wrote:

>That said, at this point, I'd just about rather have _anything_ merged
>than the nothing we have at this point.  As we throw patches back and
>forth, we can't seem to agree on even some very small points.  
>
>I also have a sinking feeling that everybody has gone back off and
>continues to develop their own out-of-tree functionality, deepening the
>patch divide.
>
>Is there anything we could merge that we _all_ don't like?  I'm pretty
>convinced that no single solution will support Eric's, OpenVZ's, and
>VServer's _existing_ usage models.  Somebody is going to have to bend,
>or nothing will ever get merged.  Any volunteers? ;)
>  
>

I don't think they're all that different conceptually.  If something as
simple as this was merged then we'd at least have a common structure to
throw things in, and a common syscall infrastructure that can gracefully
handle kernel API versioning without requiring dozens of syscalls.

>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 :-).

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 :-).

>	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), and does not
provide functions such as looking up a container by ID etc.  I think
Herbert's context.c is a pretty nice basic set of functions for dealing
with container-like things.

Thanks for your feedback!
Sam.

  reply	other threads:[~2006-03-21 21:08 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 [this message]
2006-03-21 21:32     ` Dave Hansen
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=44206B58.5000404@vilain.net \
    --to=sam@vilain.net \
    --cc=akpm@osdl.org \
    --cc=dev@openvz.org \
    --cc=ebiederm@xmission.com \
    --cc=haveblue@us.ibm.com \
    --cc=herbert@13thfloor.at \
    --cc=linux-kernel@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.