From owner-freebsd-arch Fri Nov 2 12: 0:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 8C48F37B407; Fri, 2 Nov 2001 12:00:17 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA47173; Fri, 2 Nov 2001 11:40:47 -0800 (PST) Date: Fri, 2 Nov 2001 11:40:45 -0800 (PST) From: Julian Elischer To: John Baldwin Cc: Kelly Yancey , arch@FreeBSD.ORG, Robert Watson , Garance A Drosihn Subject: Re: Changes to suser() and friends In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Fri, 2 Nov 2001, John Baldwin wrote: [...] > valuable, but having drivers and filesystems be able to handle threads and > procs in the abstract instead of having to muck with their innards is cleaner. > These two functions remove any ambiguity about what ucred is being used as well. > > int suser(struct thread *td, int flags) > Uses td->td_proc->td_ucred for its ucred. Fairly soon it will switch > to td->td_ucred when that is safe to do so. Note that this will only > be useful for curthread. If it is only useful for curthread (why?) then why specify the thread at all..? just use curthread internally.. (or maybe it IS usable for another thread in some cases?) The problem here, is that there are still plenty of cases where suser() is testing a PROCESS, because there is no indication as to which thread would be chosen to use instead.. e.g. in a function void fred(struct proc *p) { [...] suser(td); /* where did we get that td from? */ [...] } hmmm actually looking in the kernel, I noticed that most of those seem to have gone away anyhow... ignore me.. I plead old-age. > int suser_cred(struct ucred *cred, int flags) > Uses cred for its ucred. Useful in places where you want to > use a ucred other than a thread's ucred. > > suser() really is all about ucreds, so I can appreciate Robert's > desire to have one function that just takes a ucred, but I like > preserving the existing abstraction of d_thread_t. It will also make > keeping code portable between 4.x and 5.x easier. EEK! That was defined as only being useful in the context of device entrypoints..... I see creeping murk here! > > -- > > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message