Date: Sun, 17 Feb 2002 21:28:47 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Terry Lambert <tlambert2@mindspring.com>, Julian Elischer <julian@elischer.org>, Alfred Perlstein <bright@mu.org>, arch@FreeBSD.ORG, jhb@FreeBSD.ORG, peter@wemm.org, jake@locore.ca Subject: Re: gettimeofday() and crhold()/crfree() (was Re: gettimeofday()and copyout(). Is copyout() MPSAFE on non-i386 archs? ) Message-ID: <6008.1013977727@critter.freebsd.dk> In-Reply-To: Your message of "Sun, 17 Feb 2002 12:11:54 PST." <200202172011.g1HKBsv88526@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200202172011.g1HKBsv88526@apollo.backplane.com>, Matthew Dillon wri
tes:
>:Peter and I actually had a sligthly different idea:
>:
>:Add a new syscall:
>:
>: int getkernstuff(struct kernstuff *kp);
>:
>: struct kernstuff {
>: u_int32_t version;
>: pid_t pid, ppid;
>: uid_t uid, euid ...
>: gid_t gid, guid ...
>: signal masks
>: ...
>: }
>:
>:The idea here being that the userland process registers a single
>:static structure with the kernel. Inside libc, this structure
>:can be used to speed up signal processing and much more.
>
> This would make time-of-day updates rather costly.
The above was not meant for time-of-day stuff but for all the
"per process" stuff, in particular signal masks.
If we want to do fancy timekeeping, I have/had a patch which put
the timecounters on a single page which a process could map (hacked
with a special device driver). Provided that the process has acccess
to reading the timecounter (== not i8254) all the time-calculations
can be done in userland without any calls into the kernel.
This was a design parameter for timecounters, I have just never
gotten around to commit the stuff.
It is an optimization which I think is not quite needed yet and I
certainly have other things in my queue with higher priority right
now.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6008.1013977727>