From owner-freebsd-arch Thu Dec 13 18:48:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from bazooka.trit.org (bazooka.trit.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 75AA237B417; Thu, 13 Dec 2001 18:48:30 -0800 (PST) Received: by bazooka.trit.org (Postfix, from userid 1000) id D2A6F3E35; Fri, 14 Dec 2001 02:48:29 +0000 (UTC) Received: from bazooka (localhost [127.0.0.1]) by bazooka.trit.org (Postfix) with ESMTP id D12E73C12E; Fri, 14 Dec 2001 02:48:29 +0000 (UTC) To: "Brian F. Feldman" Cc: Robert Watson , arch@freebsd.org Subject: Re: MFC'ing xucred definition In-Reply-To: <200112131511.fBDFBHE78634@green.bikeshed.org>; from green@freebsd.org on "Thu, 13 Dec 2001 10:11:17 -0500" Date: Fri, 14 Dec 2001 02:48:24 +0000 From: Dima Dorfman Message-Id: <20011214024829.D2A6F3E35@bazooka.trit.org> 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 "Brian F. Feldman" wrote: > 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. > > > > 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. I'm sure there was a reason I named it cr_xversion, but I can't remember it now :-/. I've made both of these changes; you can find the new patch at http://www.trit.org/~dima/home/a/crxver.diff (I'm not posting it since there's nothing terribly interesting in it compared to the old one). Barring any objections, I plan to commit it this weekend, and MFC the xucred definition, along with my LOCAL_PEERCRED changes, some time before the 4.5 freeze. > > (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). So am I right in saying it should be kept mostly in sync with kern/? In that case, it might be worth sticking some notices to that effect in the affected files, since people will probably miss the duplicates. Thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message