On Tue, 2008-11-11 at 00:14 +0000, Charles Forsyth wrote:
> >But wouldn't you agree that files kept on a remote POSIX file system is
> >an important and common class of remotes resources for which we don't
> >quite have a consensus on how to use 9P?
>
> yes, but both your examples are things of purely local significance.
Sorry I'm confused, which examples are you talking about? Anyway, for
the sake of this conversation lets focus on: using 9P as the means to
access files on a remote POSIX filesystem.
> the symbolic links point to something local (or not), and the major/minor
> numbers are decidedly only local (since they index a kernel's data
> structures!).
> sorry, to which they refer.
This approach seems to be flawed on two accounts:
1. it forces the server to resolve symlinks and special
nodes, without an option for the client to do the same.
That prevents cross-tree symlinks and nodes as the
points of rendezvous *on the client*. IOW, the following
will not work:
$ mknod <imported FS>/test p
$ echo test >> <imported FS>/test &
cat <imported FS>/test
I can buy a point of view that reading on a node that happens
to be a character device should really bring the data from
the remote server's device attached to that node. However,
that point of view is much more difficult to sell for
FIFOs.
2. It doesn't let manipulate these special files. IOW,
readlink(2) fails and so does mknod(2)/symlink(2).
For the practical application of 9P a failing symlink(2) is a big
source of problems.
In fact, "why does my build fail" was the first question that people
asked me once I demonstrated my prototype of drawterm written in
Java. It fails because it tries to symlink within a tree that
is exported.
Thanks,
Roman.
