From owner-freebsd-arch Fri Nov 2 12:20:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id 0B49E37B403 for ; Fri, 2 Nov 2001 12:20:13 -0800 (PST) Received: (qmail 27915 invoked from network); 2 Nov 2001 20:20:11 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 2 Nov 2001 20:20:11 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 02 Nov 2001 12:20:11 -0800 (PST) From: John Baldwin To: Julian Elischer Subject: Re: Changes to suser() and friends Cc: Garance A Drosihn , Robert Watson , arch@FreeBSD.ORG, Kelly Yancey 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 02-Nov-01 Julian Elischer wrote: > > > 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 For compatibility in drivers that call suser() for 4.x and 5.x. I guess also for the same reason we insist on passing down curthread to syscalls and vops instead of assuming curthread. > 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! And if a device driver is calling suser()? This makes that case easier to maintain for the driver author since the code wont' care if this is a thread or proc, and so a simple #define suser(x,y) suser(x) can be used to make -current code work on -stable. -- 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