public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kirill Korotaev <dev@sw.ru>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Kirill Korotaev <dev@openvz.org>,
	Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	frankeh@watson.ibm.com, clg@fr.ibm.com, haveblue@us.ibm.com,
	greg@kroah.com, alan@lxorguk.ukuu.org.uk, serue@us.ibm.com,
	arjan@infradead.org, Rik van Riel <riel@redhat.com>,
	Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
	Andrey Savochkin <saw@sawoct.com>,
	devel@openvz.org
Subject: Re: [RFC][PATCH 3/5] Virtualization/containers: UTSNAME
Date: Mon, 06 Feb 2006 11:53:26 +0300	[thread overview]
Message-ID: <43E70E86.9080908@sw.ru> (raw)
In-Reply-To: <m1r76guccm.fsf@ebiederm.dsl.xmission.com>

> I am disturbed by the introduction of #defines like current_vps() and
> vps_utsname.
> 
> Magic lower case #defines are usually a bad idea.  
It is not magic defines, this is done intentionally.
You can take a more detailed view into OpenVZ sources, but the idea is 
to make kernel compilable without virtualization.
When virtualization is OFF all this macros are defined to trivial 
variables/defines which make it an old good kernel.

For example current_vps() should be (&init_vps), i.e. host system 
environment only.

vps_utsname will be defined as system_utsname and so on.

> These defines hide the cost of the operations you are performing.
> At that point you might as well name the thing system_utsname
> so you don't have to change the code.  
You mean to have variable and define with the same names?
it is not always good. It works fine, when both are defined in the same 
file, but poorly when it is scattered all around...

> And of course you failed to change several references to
> system_utsname.
which one? Maybe intentionally? ;-)
Kirill







  reply	other threads:[~2006-02-06  8:52 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-03 16:58 [RFC][PATCH 1/5] Virtualization/containers: startup Kirill Korotaev
2006-02-03 17:03 ` [RFC][PATCH 2/5] Virtualization/containers: UIDs Kirill Korotaev
2006-02-03 17:06 ` [RFC][PATCH 3/5] Virtualization/containers: UTSNAME Kirill Korotaev
2006-02-06  8:21   ` Eric W. Biederman
2006-02-06  8:53     ` Kirill Korotaev [this message]
2006-02-03 17:15 ` [RFC][PATCH 1/5] Virtualization/containers: startup Linus Torvalds
2006-02-03 17:22   ` Kirill Korotaev
2006-02-03 17:49     ` Linus Torvalds
2006-02-03 18:34       ` Dave Hansen
2006-02-03 18:55         ` Jeff Garzik
2006-02-03 19:18         ` Hubertus Franke
2006-02-03 19:56         ` Hubertus Franke
2006-02-03 20:19         ` Greg KH
2006-02-03 20:34           ` Hubertus Franke
2006-02-05 15:11             ` Kirill Korotaev
2006-02-05 15:39               ` Hubertus Franke
2006-02-06  9:08                 ` Kirill Korotaev
2006-02-06 22:31               ` Cedric Le Goater
2006-02-07 12:28                 ` Kirill Korotaev
2006-02-05 15:10           ` Kirill Korotaev
2006-02-05 15:05         ` Kirill Korotaev
2006-02-06 16:35           ` Dave Hansen
2006-02-06 16:51             ` Kirill Korotaev
2006-02-06 16:56           ` Linus Torvalds
2006-02-06 17:21             ` Kirill Korotaev
2006-02-07  0:28             ` Sam Vilain
2006-02-07 12:21               ` Kirill Korotaev
2006-02-07 22:21                 ` Sam Vilain
2006-02-20 11:56                   ` Kirill Korotaev
2006-02-03 18:36       ` Summary: PID virtualization , Containers, Migration Hubertus Franke
2006-02-03 18:36       ` [RFC][PATCH 1/5] Virtualization/containers: startup Rik van Riel
2006-02-05 14:52       ` Kirill Korotaev
2006-02-06  8:39       ` Eric W. Biederman
2006-02-06  9:00         ` Kirill Korotaev
2006-02-06  9:19           ` Eric W. Biederman
2006-02-06 16:37             ` Dave Hansen
2006-02-06 18:37               ` Eric W. Biederman
2006-02-06 19:32                 ` Kirill Korotaev
2006-02-06 22:40                 ` Cedric Le Goater
2006-02-07  1:57                   ` Eric W. Biederman
2006-02-08 21:54                 ` swsusp done by migration (was Re: [RFC][PATCH 1/5] Virtualization/containers: startup) Pavel Machek
2006-02-09 18:20                   ` Eric W. Biederman
2006-02-10  0:21                     ` Kyle Moffett
2006-02-10  4:31                       ` Sam Vilain
2006-02-10  6:23                         ` [Devel] " Vasily Averin
2006-02-11  2:38                           ` Sam Vilain
2006-02-11 17:29                             ` Vasily Averin
2006-02-12 23:29                               ` Sam Vilain
2006-02-10  8:29                         ` Kyle Moffett
2006-02-10  5:40                 ` [RFC][PATCH 1/5] Virtualization/containers: startup Nigel Cunningham
2006-02-10  6:01                   ` Eric W. Biederman
2006-02-06 10:16   ` Jes Sorensen
2006-02-05 20:13 ` Andi Kleen
2006-02-06  9:04   ` Kirill Korotaev
2006-02-06  0:56 ` Benjamin Herrenschmidt
2006-02-06  9:03   ` [Devel] " Kirill Korotaev
2006-02-06  8:31 ` Eric W. Biederman

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=43E70E86.9080908@sw.ru \
    --to=dev@sw.ru \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arjan@infradead.org \
    --cc=clg@fr.ibm.com \
    --cc=dev@openvz.org \
    --cc=devel@openvz.org \
    --cc=ebiederm@xmission.com \
    --cc=frankeh@watson.ibm.com \
    --cc=greg@kroah.com \
    --cc=haveblue@us.ibm.com \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@redhat.com \
    --cc=saw@sawoct.com \
    --cc=serue@us.ibm.com \
    --cc=torvalds@osdl.org \
    /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