Date: Thu, 30 Nov 2000 10:48:43 +0100 (CET) From: Andrzej Bialecki <abial@webgiro.com> To: Terry Lambert <tlambert@primenet.com> Cc: Alfred Perlstein <bright@wintelcom.net>, arch@FreeBSD.ORG Subject: Re: HEADSUP user struct ucred -> xucred (Was: Re: serious problem with mutexs and userland visibility?) Message-ID: <Pine.BSF.4.20.0011301037190.51755-100000@mx.webgiro.com> In-Reply-To: <200011300628.XAA06955@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 30 Nov 2000, Terry Lambert wrote: > > > Unfortunetly struct ucred is used by some userland utils and > > > sys/ucred is included in sys/mount.h as well as sys/user.h, this > > > creates somewhat of a problem, forcing all users of sys/ucred.h to > > > include sys/mutex.g. > > > > > > I have a patch here that sort of takes care of this problem, the > > > problem is that I had to add sys/mutex.h includes to both sys/mount.h > > > and sys/user.h, this doesn't make me very happy. > > > > 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. > > > > Struct ucred will no longer be visible outside the kernel. > > > > Any userland things using struct ucred will need to use xucred. > > > > This will be the convention used to resolve mutex (or other MD > > fields) in kernel exported structures in the future. > > This is a really gross way to handle this. The ucred structure > is used by a lot of user space programs. > > 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. 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? :-). This way no user space code will have to be changed (more than today, i.e. recompile libkvm et al., as usual), we could hide the complexities that we don't want to be visible outside the kernel, and we gain the stability in kernel/user interface (i.e. no more recompiles of userland needed if you update the kernel with changed struct proc size). Andrzej Bialecki // <abial@webgiro.com> WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- 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?Pine.BSF.4.20.0011301037190.51755-100000>