Date: Tue, 17 Jan 2006 09:56:00 -0600
From: "Serge E. Hallyn" <serue@us.ibm.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Serge Hallyn <serue@us.ibm.com>, linux-kernel@vger.kernel.org,
       Hubertus Franke <frankeh@watson.ibm.com>,
       Cedric Le Goater <clg@fr.ibm.com>, Dave Hansen <haveblue@us.ibm.com>
Subject: Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
Message-ID: <20060117155600.GF20632@sergelap.austin.ibm.com>
References: <20060117143258.150807000@sergelap> <20060117143326.283450000@sergelap> <1137511972.3005.33.camel@laptopd505.fenrus.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1137511972.3005.33.camel@laptopd505.fenrus.org>
User-Agent: Mutt/1.5.11
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1458
Lines: 34

Quoting Arjan van de Ven (arjan@infradead.org):
> On Tue, 2006-01-17 at 08:33 -0600, Serge Hallyn wrote:
> > plain text document attachment (BC-define-pid-handlers)
> > Actually define the task_pid() and task_tgid() functions.  Also
> > replace pid with __pid so as to make sure any missed accessors are
> > caught.
> 
> This question was asked a few times before without satisfactory answer:
> *WHY* this abstraction.
> There is *NO* point. Really. 
> 
> (And if the answer is "but we want to play tricks later", just make a
> current->realpid or whatever, but leave current->pid be the virtual pid.
> Your abstraction helps NOTHING there. Zero Nada Noppes).

The virtual pid is different depending on who is asking.  So simply
storing current->realpid and current->pid isn't helpful, as we would
still need to call a function when a pid crosses user->kernel boundary.

However we could make the patch far less invasive by skipping the
task_pid() macro altogether.  Switching current->pid to current->__pid
was to make sure we catch any ->pid accesses which we may have missed,
during compilation.

Is that approach (keeping task->pid as the real pid and dropping the
task_pid() macro) preferred by all?

-serge

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/