Date: Fri, 02 Nov 2001 12:20:11 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: Garance A Drosihn <drosih@rpi.edu>, Robert Watson <rwatson@FreeBSD.ORG>, arch@FreeBSD.ORG, Kelly Yancey <kbyanc@posi.net> Subject: Re: Changes to suser() and friends Message-ID: <XFMail.011102122011.jhb@FreeBSD.org> In-Reply-To: <Pine.BSF.4.21.0111021129270.47100-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.011102122011.jhb>