On Thu, Sep 01, 2005 at 02:49:32PM -0700, Bill Studenmund wrote:
> On Thu, Sep 01, 2005 at 04:40:28PM -0500, Eric Haszlakiewicz wrote:
> > On Thu, Sep 01, 2005 at 01:21:38PM -0700, Bill Studenmund wrote:
> > > 1) what exactly are you trying to do? A comment or two would help.
> >=20
> > 	Erase the emulation root dir from any cwd that has it.  i.e.:
> > figure out what the emulation dir (e.g. /emul/linux) actually points to.
> >   (on my machine, and most I think, /usr/pkg/emul/linux)
> > then see if the path returned from getcwd starts with that
> >   (e.g. "/usr/pkg/emul/linux/bin")
> > and if so, remove it.
> > 	(e.g. turning the path into just "/bin"
> > I'll add some comments.
>=20
> I'm not sure what I think of this. But I'll defer that for other messages=
.=20
> I am concerned that we may introduce more problems than we solve.

	I think it makes the emul path stuff act more like a chroot
environment.  The time when it might cause a problem is when that
path gets fed to something outside the "chroot", i.e. a non-emul
process.  It seems easier to think about solving issues wrt information
moving across that pseudo-root boundary, than wrt inconsistent views
of the filesystem within a single process depending on the syscall.
	However, I haven't actually come up with any concrete examples
of problems/benefits; I was kind of hoping someone here would notice
something obvious one way or the other. :)


>  * the target of the pathname exists and LOCKLEAF is or'ed into the flag
>  * the target is returned locked, otherwise it is returned unlocked.
>=20
> So vput() was wrong as the vnode wasn't locked. However you do need to do=
=20
> something to release it. vrele(). :-)

	ah, I get it now.  thanks.  I put a new patch at
ftp://ftp.netbsd.org/pub/NetBSD/misc/erh/emul/emul_getcwd.diff

eric