Subject: Re: [RFC] [PATCH 00/13] Introduce task_pid api
From: Arjan van de Ven <arjan@infradead.org>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
       "SERGE E. HALLYN [imap]" <serue@us.ibm.com>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
       Hubertus Franke <frankeh@watson.ibm.com>, Paul Jackson <pj@sgi.com>
In-Reply-To: <1133993636.30387.41.camel@localhost>
References: <20051114212341.724084000@sergelap>
	 <m1slt5c6d8.fsf@ebiederm.dsl.xmission.com>
	 <1133977623.24344.31.camel@localhost>
	 <1133978128.2869.51.camel@laptopd505.fenrus.org>
	 <1133978996.24344.42.camel@localhost>
	 <1133982048.2869.60.camel@laptopd505.fenrus.org>
	 <1133993636.30387.41.camel@localhost>
Content-Type: text/plain
Date: Wed, 07 Dec 2005 23:20:02 +0100
Message-Id: <1133994002.2869.73.camel@laptopd505.fenrus.org>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1003
Lines: 23


> 99% of the time, the kernel can deal with the same old tsk->pid that
> it's always dealt with.  Generally, the only times the kernel has to
> worry about the virtualized one is where (as Eric noted) it cross the
> user<->kernel boundary.

that's fair enough. I don't see the need for the macro abstractions
though; a current->pid and current->user_pid (or visible_pid or any
other good name) split makes sense. no need for macro abstractions at
all, just add ->user_pid in patch 1, in patch 2 assign it default to
->pid as well and patch 3 converts the places where ->pid is now given
to userspace ;)

again the DRM layer needs an audit, I'm not entirely sure if it doesn't
get pids from userspace. THe rest of the kernel mostly ought to cope
just fine.


-
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/