Date: Fri, 14 Dec 2001 02:48:24 +0000 From: Dima Dorfman <dima@trit.org> To: "Brian F. Feldman" <green@freebsd.org> Cc: Robert Watson <rwatson@freebsd.org>, arch@freebsd.org Subject: Re: MFC'ing xucred definition Message-ID: <20011214024829.D2A6F3E35@bazooka.trit.org> In-Reply-To: <200112131511.fBDFBHE78634@green.bikeshed.org>; from green@freebsd.org on "Thu, 13 Dec 2001 10:11:17 -0500"
next in thread | previous in thread | raw e-mail | index | archive | help
"Brian F. Feldman" <green@freebsd.org> wrote:
> Dima Dorfman <dima@trit.org> wrote:
> > Robert Watson <rwatson@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011214024829.D2A6F3E35>