From owner-freebsd-arch Tue Sep 4 10: 7:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 95D9437B403; Tue, 4 Sep 2001 10:07:08 -0700 (PDT) Received: (from dillon@localhost) by earth.backplane.com (8.11.6/8.11.2) id f84H78592607; Tue, 4 Sep 2001 10:07:08 -0700 (PDT) (envelope-from dillon) Date: Tue, 4 Sep 2001 10:07:08 -0700 (PDT) From: Matt Dillon Message-Id: <200109041707.f84H78592607@earth.backplane.com> To: Robert Watson Cc: arch@FreeBSD.ORG Subject: Re: ucred -> cred, cr_[ug]id References: 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 :Earlier this year, I merged the 'pcred' and 'ucred' structures into a :single 'ucred' structure, recognizing that in practice our use of pcred :and ucred was such that the costs of the change were low, but the clarity :associated with the change was relatively high. This simplified things :from a variety of perspective, including reference counting and :synchronization. This is a change also performed on a number of other :UNIX platforms, including Solaris and IRIX. However, on those platforms, :the single structure is called 'cred' and not 'ucred'. As such, I'd like :to propose that we do the following: : :o Replace all references to struct ucred with struct cred :o Repo-copy src/sys/ucred.h to src/sys/cred.h : :I don't feel all that strongly about this change, but do think it would :make sense given the use of the structure, and the evolution of other :platforms making similar classes of changes. : :On a similar note, when I merged ucred and pcred, I maintained cr_uid as :the effective uid: other platforms typically stick an 'e' in front to get :cr_euid, making it consistent with other variables in the structure. If I :were to make the 'cred' change, I'd also improve consistency by adding the :'e' to the effective uid and gid structures. : :Any strong reasons not to do this? : :Robert N M Watson FreeBSD Core Team, TrustedBSD Project :robert@fledge.watson.org NAI Labs, Safeport Network Services This sounds like a good idea to me. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message