Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 2 Nov 2001 11:40:45 -0800 (PST)
From:      Julian Elischer <julian@elischer.org>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        Kelly Yancey <kbyanc@posi.net>, arch@FreeBSD.ORG, Robert Watson <rwatson@FreeBSD.ORG>, Garance A Drosihn <drosih@rpi.edu>
Subject:   Re: Changes to suser() and friends
Message-ID:  <Pine.BSF.4.21.0111021129270.47100-100000@InterJet.elischer.org>
In-Reply-To: <XFMail.011102112429.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help


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 <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?Pine.BSF.4.21.0111021129270.47100-100000>