Date: Thu, 30 Nov 2000 22:51:25 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: bright@wintelcom.net (Alfred Perlstein) Cc: abial@webgiro.com (Andrzej Bialecki), tlambert@primenet.com (Terry Lambert), arch@FreeBSD.ORG Subject: Re: HEADSUP user struct ucred -> xucred (Was: Re: serious problem with mutexs and userland visibility?) Message-ID: <200011302251.PAA23494@usr05.primenet.com> In-Reply-To: <20001130022614.W8051@fw.wintelcom.net> from "Alfred Perlstein" at Nov 30, 2000 02:26:14 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> Ok, kvm is killing me. :/ Data interfaces suck. > 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. > > ? What happens when you add a new _not_ kernel-only field and boot an older kernel because the newer kernel is unstable? You need to get away from data interfaces. Please see my other posting in this thread: mutex protected data objects accessed via data interface in a userland which neither asserts nor honors the mutex are inhernetly SMP and kernel preemption unsafe. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?200011302251.PAA23494>