[prev in list] [next in list] [prev in thread] [next in thread]
List: linux-fsdevel
Subject: Re: Mountpoint lookup
From: David Chow <davidchow () shaolinmicro ! com>
Date: 2003-02-22 18:56:17
[Download RAW message or body]
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
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic