Re: Mountpoint lookup

[David Chow <davidchow@shaolinmicro.com>]

Florin Malita wrote:

>On Wed, 2003-02-05 at 23:15, Bryan Henderson wrote:
>  
>
>>To the extent that this translation would be handy, it would be appropriate
>>to pass the information as a filesystem-type-specific mount parameter
>>(which is actually a parameter of the filesystem image, not of the mount),
>>but the semantics of the parameter wouldn't be "this is the mount point,"
>>but rather "translate absolute symlinks with respect to this base path."
>>You could have a mount program that automatically sets this parameter to
>>the same path as the mount point, but of course you'd still have to have a
>>lot of disclaimers that imported absolute symlinks don't always work the
>>way the user expects.
>>    
>>
>
>Sounds reasonable.
>
>But how about translating all remote absolute symlinks to relative ones?
>Seems to be quite easy and eliminates any need of mount point knowledge.
>
>  
>
Actually, this question is some question I've asked before. Al response 
to me with the same answer. However, I do find it important in 
communicating with user land fs implementation or stackable fs 
implementation. However, the file system path (user space view) doesn't 
even exists after read_super() returns. I suggests the fs driver to 
implement a /proc interface for communication to user space. Because the 
user space path not always tells you or able to correctly locate the 
root dentry of your file system. Think of --bind or othermounts ontop of 
your previous mounts. User space must check fs type or as I said some 
/proc or ioctls. Symlinks is even more complicate as it can be cross 
devices, this is something impossible to handle with a couple of --bind 
on one another. You have to make your choice of assumptions.

regards,
David Chow