On Fri, Jul 08, 2005 at 04:57:25PM -0700, Bill Studenmund wrote:
> On Fri, Jul 08, 2005 at 10:35:29AM -0700, Jason Thorpe wrote:
> > 
> > On Jul 8, 2005, at 10:23 AM, Chuck Silvers wrote:
> > 
> > >I think that the real problem is having the path interpretation be  
> > >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"  
> > >provides.
> > >
> > >then readlink() would be fine as it is.
> > 
> > So, the question is:
> > 
> > Are these magic names interpreted by lookup() before handing them off  
> > to VFS_LOOKUP()?  I would guess it would have to be, otherwise it  
> > would just be insane.
> 
> My thought is to keep the processing in namei(). Just change it so that 
> rather than looking at a path passed from a symlink (i.e. after lookup() 
> returns), we look at all paths before we call lookup().

I'll leave this level of detail to you folks that are more familiar with it.


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

I also think that having this be configured per-system instead of per-mount
probably makes more sense.  otherwise you get into the confusing situation
of having a symlink containing one of these magic names that lives in one fs
but that points through another (or maybe several others), with the different
fs's having different settings for magic names being enabled.  well...
with NFS there's the same issue with different nodes having different settings,
so I guess it's really unavoidable.  per-node seems like it would probably
be less bad, though.

-Chuck