Subject: Re: CVS commit: src/sys
To: None <tls@rek.tjls.com>
From: Christos Zoulas <christos@zoulas.com>
List: tech-kern
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