Re: [9fans] Do we have a catalog of 9P servers?

["Bruce Ellis" <bruce.ellis@gmail.com>]

Why does your build fail? Lack of vision to the extreme resulting in a
completely horrible way of building things that has grew and grew to
something that not even its mother could not love.

In some sense it's good that it fails. If you want to build things
that way then don't use plan9. Seriously. The simplest program is now
entangled in the most horrendous config/build mess. Why? Because
that's how you do things. No!!!

"Hideous, horrible!" - as a friend at the Labs would shout (not about
CS, he was a physicist).

As for mknod, I don't think it's worth trying to keep that alive, let
alone breaking plan9 to do it.

brucee

On Tue, Nov 11, 2008 at 3:00 AM, Roman V. Shaposhnik <rvs@sun.com> wrote:
> 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.
>
>
>