--LZvS9be/3tNcYl/X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 08, 2005 at 10:35:29AM -0700, Jason Thorpe wrote:
>=20
> On Jul 8, 2005, at 10:23 AM, Chuck Silvers wrote:
>=20
> >I think that the real problem is having the path interpretation be =20
> >different
> >for symlinks vs. other path lookups done in the kernel.  it would make
> >a lot more sense to have the tranlation done for all pathname lookups
> >or none, and not this awkward halfway thing that "magic symlinks" =20
> >provides.
> >
> >then readlink() would be fine as it is.
>=20
> So, the question is:
>=20
> Are these magic names interpreted by lookup() before handing them off =20
> to VFS_LOOKUP()?  I would guess it would have to be, otherwise it =20
> would just be insane.

My thought is to keep the processing in namei(). Just change it so that=20
rather than looking at a path passed from a symlink (i.e. after lookup()=20
returns), we look at all paths before we call lookup().

I realize that this change would require magicname handling to be=20
system-wide rather than per-mountpoint. I think that's fine. After all,=20
the semantics are system-wide.

Take care,

Bill

--LZvS9be/3tNcYl/X
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFCzxLlWz+3JHUci9cRAsiNAJ9CmD7rWBqibBXvblDz5R4APeWrBgCfS04s
UzUq8Ofu98km8cCbsONjo/M=
=TuO3
-----END PGP SIGNATURE-----

--LZvS9be/3tNcYl/X--