Date: Thu, 30 Nov 2000 02:26:14 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Andrzej Bialecki <abial@webgiro.com> Cc: Terry Lambert <tlambert@primenet.com>, arch@FreeBSD.ORG Subject: Re: HEADSUP user struct ucred -> xucred (Was: Re: serious problem with mutexs and userland visibility?) Message-ID: <20001130022614.W8051@fw.wintelcom.net> In-Reply-To: <Pine.BSF.4.20.0011301037190.51755-100000@mx.webgiro.com>; from abial@webgiro.com on Thu, Nov 30, 2000 at 10:48:43AM %2B0100 References: <200011300628.XAA06955@usr08.primenet.com> <Pine.BSF.4.20.0011301037190.51755-100000@mx.webgiro.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Andrzej Bialecki <abial@webgiro.com> [001130 01:50] wrote: > On Thu, 30 Nov 2000, Terry Lambert wrote: > > > > After a short discussion it has been determined that there will be > > > a xucred exported to userland following the concention of xsocket > > > and the various other xfoo structs exported to the kernel. > > > > You should do what several UNIX vendors have already done, and > > implement a MUTEX() declaration macro that differes in user and > > kernel space, and forces an alignment; then when you copy out, > > copy out everything _BUT_ the mutex portion to the user space, > > and no user space source or object code will need to change. > > But don't we have the same issue with other parts of kernel structures > that we don't want to make visible to userland, not just the > mutexes. True. > I had some discussion with Robert Watson a few days ago about the need to > hide the layout of struct proc (and the changes it undergoes) from > userland, which would allow to stabilize kernel interface to user > utilities, like libkvm and friends (which probably should use > specialized sysctl anyway). This goal would be quite difficult to achieve > with just macros (and ugly at that..), so we thought about fixing all > places where these structs are accessible to use special version of "user > space struct proc" (== struct xproc? :-). Ok, kvm is killing me. :/ see: ~"lib/libkvm/kvm_proc.c" line 125 of 793 libkvm expects to be able to copy the pointer in the struct proc into its own struct. My only chance (or so it seems) is to keep all userland visible parts of the ucred at the begininning of it, as well as forcing the same order to keep libkvm happy. Then it can effectively: bcopy(struct ucred *uc, struct xucred *xuc, sizeof(struct xucred)); without worries, this is pretty hackish, but libkvm isn't exactly your state of the art interface. This is pretty close to what Terry suggested but less scary in my opinion as long as we add a comment to sys/ucred.h about keeping kernel only feilds at the end of the struct. ? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." 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?20001130022614.W8051>