From: David Butler gdb@dbsystems.com
Subject: [9fans] Re: 9p question
Date: Fri, 10 Mar 2000 09:23:19 +0000 [thread overview]
Message-ID: <20000310092319.iH33whV7qgZUvdWhoS3ShU9sJMMEYsSjSsjY3uUKLo0@z> (raw)
rob pike <rob@plan9.bell-labs.com> wrote in message
news:200003091350.IAA23914@cse.psu.edu...
> > The real reason for the "lengthy" conversation is the Tclone/Twalk
> > part. That is part of the price that is paid to remove the '/' as a
> > directory separator
>
> No.
Is that 'no' the conversation is lengthy, 'no' that it is part of the
price to remove '/' or 'no' that removing '/' was a goal?
[snip]
>elements (requiring the server to parse and understand '/'), but
>it's such a pain to change the protocol.
I hope if you though it "better" it would be worth the "pain".
(Not that I think it "better", I don't.)
[reorder]
> The real reason is that after each walk the client must check whether
>the point-so-far is in the mount table. That's why it's done a path
[snip]
>Seeking on a directory is forbidden because it's hard enough to
>implement reading a union directory without seek. The internal
By your own point union directories are handled in the Twalk.
What does that have to do with reading a directory?
>structure that must be maintained in the kernel was deemed too
>hard to maintain other than by sequential access, so we made
>seeking on a directory illegal. It didn't seem worth the implementation
>overhad.
Back to the better/pain discussion, again. I thought the limitations
to restrictive and worked out a better one. Yes, it was painful, but
the result was well worth the effort.
> I still feel that way.
I'm glad. I won't have to integrate a conflicting solution when,
if ever, Release II(TM) sees the light of day...
next reply other threads:[~2000-03-10 9:23 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-03-10 9:23 David [this message]
-- strict thread matches above, loose matches on Subject: below --
2000-03-16 14:05 presotto
2000-03-14 14:51 forsyth
2000-03-13 12:01 Roman
2000-03-13 9:28 Douglas
2000-03-11 15:00 rob
2000-03-11 9:53 Vladimir
2000-03-10 11:02 forsyth
2000-03-10 9:23 Roman
2000-03-09 19:04 forsyth
2000-03-09 18:10 Roman
2000-03-09 18:05 Roman
2000-03-09 15:33 presotto
2000-03-09 14:44 Roman
2000-03-09 14:21 Roman
2000-03-09 13:50 rob
2000-03-09 13:18 presotto
2000-03-09 10:50 forsyth
2000-03-09 10:39 forsyth
2000-03-09 10:02 Douglas
2000-03-09 9:26 Roman
2000-03-07 9:32 David
2000-02-28 18:07 rob
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20000310092319.iH33whV7qgZUvdWhoS3ShU9sJMMEYsSjSsjY3uUKLo0@z \
--to=9fans@9fans.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).