From owner-freebsd-arch Thu Dec 13 7:11:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from green.bikeshed.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id F2D6D37B405; Thu, 13 Dec 2001 07:11:25 -0800 (PST) Received: from localhost (green@localhost) by green.bikeshed.org (8.11.6/8.11.6) with ESMTP id fBDFBHE78634; Thu, 13 Dec 2001 10:11:24 -0500 (EST) (envelope-from green@green.bikeshed.org) Message-Id: <200112131511.fBDFBHE78634@green.bikeshed.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Dima Dorfman Cc: Robert Watson , arch@freebsd.org Subject: Re: MFC'ing xucred definition In-Reply-To: Message from Dima Dorfman of "Thu, 13 Dec 2001 03:58:58 GMT." <20011213035903.AA8603E2F@bazooka.trit.org> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Dec 2001 10:11:17 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dima Dorfman wrote: > Robert Watson wrote: > > I've actually been thinking about modifying xucred in -CURRENT to export > > additional information from a kernel ucred, such as real and saved ids, > > now that we have that information in ucred. > > Some users of xucred wouldn't know what to do with these extra fields, > since they just use xucred to pass a uid/gid to/from the kernel. The > NFS export stuff is one of these, I think. > > > Before we MFC xucred, it > > might make sense to make a few tweaks to xucred, including changing the > > first _cr_unused0 into a version number, and teaching applications how to > > understand the version number. > > I don't know what other tweaks you had in mind (perhaps making it > larger?), but the version number seems like a good idea. > > I've attached a patch that makes the first field a version number, and > teaches the existing applications about it (mostly, it teaches them > set the version when writing an xucred, and return EINVAL if it > doesn't match when reading an xucred). It compiles and seems to run, > but I have not done extensive testing with it. Please review. Yes, this looks like just what I intended we should do with xucred {} if we ever decided to want to export more fields. I like the changes, except for a few smaller things. In the interest of compatibility, XUCRED_VERSION should start at 0, or it will needlessly break several applications. The other is that I am curious why the new field is named cr_xversion and not just cr_version. I'd be much more comfortable with cr_version, which would coincide with the naming of the #define you chose of XUCRED_VERSION. > (Note that this patch changes something inside lomac which looks like > it was copied verbatim from uipc_usrreq.c. I don't know anything > about lomac, but my guess is that this code should be kept somewhat in > sync (although I haven't seen any posts/warnings to that effect). If > anyone can shed any light on this, I'd appreciate it). That is indeed the case. That bit of code would have to either have been copied for use there or modified wholesale (which would be somewhat evil). Anyway, all seems to be correct even if I'd rather those two small changes were made. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message