Date: Sun, 17 Feb 2002 16:13:02 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Matthew Dillon <dillon@apollo.backplane.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: <3C70470E.BD2F048D@mindspring.com> References: <5405.1013975811@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote:
> 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.
>
> The kernel accesses the structure in userland with copyin/copyout/fubyte,
> and the usage of this feature is entirely optional, programs don't
> have to do it.
I guess this would be read/write?
I don't think copyin() access would be the best way to
do it, if that's the case, since the user could lie to
the kernel that way.
That makes the user space data a reflection of the
kernel data, which is, in a way, acceptable, I guess.
I personally wouldn't be adverse to mapping the proc
structure read-only into user space, and page aligning
the allocations.
The problem is with the page sized requirement eating
a potentially large chunk of the address space. For
example, a "safe" thing for the kernel to access would
be a per process dual mapped page (e.g. a kernel page
pointed to by the proc struct, where the PG_U bit was
simply set on the page, and the address known to user
space), which wouldbe used as mailbox for threads, and
where it would be OK for the user space threads scheduler
to keep context the kernel might want, like current thread
ID.
Per process stuff is much more difficult because of the
address space bloat and the page size restriction, than
something like getimeofday, which could be read-only in
all user space processes fairly painlessly.
In any case, soing this for other rarely changed values,
where the copy is reflected out but not in, could work
with a user registration, as you suggest. It'd probably
be a lot better way of handling the getpid/getgid/etc.
stuff than crossing the system call boundary, and taking
lots of credential locks, etc..
Frankly, I think there are a lot of places where there
is a credential present where there is really not a lot
of need for the credential to be there, and that making
the interfaces homogeneous in places where it doesn't
make a lot of sense to do that is really costing FreeBSD
some performance.
I never really understood the requirement for getimeofday
to have these restrictions, to point back to the current
discussion.
-- Terry
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?3C70470E.BD2F048D>