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>