From owner-freebsd-arch Thu Nov 30 14:51:43 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 1FF6237B400 for ; Thu, 30 Nov 2000 14:51:41 -0800 (PST) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id PAA08490; Thu, 30 Nov 2000 15:47:13 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpdAAA3WaqHq; Thu Nov 30 15:47:04 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id PAA23494; Thu, 30 Nov 2000 15:51:25 -0700 (MST) From: Terry Lambert Message-Id: <200011302251.PAA23494@usr05.primenet.com> Subject: Re: HEADSUP user struct ucred -> xucred (Was: Re: serious problem with mutexs and userland visibility?) To: bright@wintelcom.net (Alfred Perlstein) Date: Thu, 30 Nov 2000 22:51:25 +0000 (GMT) Cc: abial@webgiro.com (Andrzej Bialecki), tlambert@primenet.com (Terry Lambert), arch@FreeBSD.ORG In-Reply-To: <20001130022614.W8051@fw.wintelcom.net> from "Alfred Perlstein" at Nov 30, 2000 02:26:14 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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