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>