Subject: Re: CVS commit: src/sys
To: None <tls@rek.tjls.com>
From: Christos Zoulas <christos@zoulas.com>
List: tech-security
Date: 06/24/2007 22:55:37
On Jun 24, 10:19pm, tls@rek.tjls.com (Thor Lancelot Simon) wrote:
-- Subject: Re: CVS commit: src/sys

| On Sun, Jun 24, 2007 at 10:13:16PM -0400, Christos Zoulas wrote:
| > 
| > It would be nice if someone implemented a commpage for NetBSD and stuffed all
| > this info there.
| 
| This isn't what would go in the traditional "commpage" which is common
| between *all* user processes and the kernel, because (for example) the result
| of getpid() is specific to *each process*.  The result of getpid() belongs
| in a local variable in each process, I believe, reset at fork() time in
| each child.

I don't know the exact details, but darwin has thread_self in their commpage.
Isn't that process specific too?

| We could implement two "commpages" per process: one shared between the kernel
| and *all* processes (for gettimeofday(), cpu-optimized memcpy() etc, and that
| sort of thing) and another shared between the kernel and *each* process (for
| getpid(), getppid(), and so forth) but why pay the penalty of accessing a
| shared page if you don't have to?

What is the cost of that? The page should be resident...

| Perhaps this would be a reasonably elegant way to handle getppid() without
| any kind of asynchronous notification to the process, though.  But for
| getpid() a local variable will do -- unless you see some reason why it
| won't?

I am just saying that it is easier to put everything in one place, rather
than special casing the easy syscalls.

christos