On Sunday 13 March 2005 14:30, Chuck Silvers wrote:
> On Wed, Mar 09, 2005 at 08:23:16AM +0000, Nick Hudson wrote:
> > > I think that uio_procp was originally used more to refer to the address
> > > space than the thread, so it would be good to take a look at which (if
> > > any) paths actually need the lwp pointer and see if they can get it
> > > some other way. I took a quick look at this and almost all of the uses
> > > are just to get at the proc.
> >
> > So, I traced a few of the uio_lwp users and found the following
> >
> >  - coda_{read,write} => coda_rdwr => VOP_{OPEN,CLOSE}
> >  - coda_readdir => VOP_{OPEN,CLOSE}
> >
> > I'm still digging.
>
> ok, but do VOP_OPEN and VOP_CLOSE actually use the lwp argument?

The VOP_OPEN users I've found are:

union_open - the lwp is passed to union_copyup to union_vn_create which 
creates a struct componentname for relookup(9). struct componentname has 
s/cn_proc/cn_lwp/ for ktrnamei.

procfs_open => process_checkioperm => proc_isunder => vn_isunder => 
getcwd_scandir which is another struct componentname

It would appear that the struct componentname change affects far more than is 
obvious.

Still digging on other uio_lwp users...

Nick