9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "boyd, rounin" <boyd@insultant.net>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] Rstat needs three size fields?
Date: Tue,  1 Jul 2003 23:46:47 +0200	[thread overview]
Message-ID: <00ce01c3401a$45a9f740$d2944251@insultant.net> (raw)

Sam asked me:

> OK, I've been thinking about this a day now and I'm
> not sure what you mean.  There shouldn't be any partial
> directory entries, right?

in the 'old days' directories had a fixed size [2 byte inode
number + 14 byte name].  so it was easy.  you could cheat
and statically allocate and we mainly did 'cos calling malloc
was a big no-no, 'cos there was next to no memory and cpu
was scarce.

then came along BSD which gave us these lunatic long names
and a namei() that took years to fix.  so you used readdir()
and a chunk of crap because just calling read was now
_too hard_ -- in fact it was illegal.

then we had NFS.  and so you had to ask the server to send
across some number of directory entries [getdents()] and this
sat under readdir().  this was all very fine, but now you
had a bunch of library functions and system calls and NFS
protocol garbage and you couldn't use read() anymore.

in fact _the only place_ the XDR encode/decode code
existed for directory entries was _in the kernel_.  that
stuff was really 'fascinating' ...

    Brushes with death were described as "fascinating."
    To be "absolutely fascinated" meant scared witless.

        -- http://www.air-america.org/Articles/Doole.htm

should you have had ultrix and wanted to write a user-mode NFS
server you had to either get a protocol analyser, tcpdump,
dick around, guess or get hold of the code.

[i wrote an NFS version of ftpfs]

there was never anything wrong with read().  the proliferation of
crap, as a result of BSD long names, added an immense amount
of useless baggage.

should read() return partial directory entries you are in a world of
pain because you have to maintain state so that you can pick up
where you left off and try and glue the partials back together.

so the solution is to just use read() and return whole directory
entries; it simplifies things on both the client and server side.
should read return 0, multiply the malloc()'d buffer by 2, realloc()
and loop.

it helps if you have some side information so that when the read()
returns you have a clue of how much stuff is in the buffer, 'cos
buffer overruns are not your friend.

i suspect the extra size info is 'side information'.



             reply	other threads:[~2003-07-01 21:46 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-01 21:46 boyd, rounin [this message]
2003-07-02 18:49 ` [9fans] Python? Jack Johnson
2003-07-03  0:34   ` boyd, rounin
  -- strict thread matches above, loose matches on Subject: below --
2003-07-02  0:24 [9fans] Rstat needs three size fields? boyd, rounin
2003-06-30 18:04 Sam
2003-06-30 19:08 ` ron minnich
2003-06-30 19:15   ` boyd, rounin
2003-07-04  3:18 ` Russ Cox
2003-07-04 15:04   ` Sam
2003-07-04 17:13     ` rob pike, esq.
2003-07-07  8:33       ` Douglas A. Gwyn
2003-07-07  9:03         ` Geoff Collyer
2003-07-07 15:10           ` Douglas A. Gwyn
2003-07-08  0:49             ` ron minnich
2003-07-07 15:50           ` rob pike, esq.
2003-07-07 20:38             ` boyd, rounin
2003-07-07 21:18               ` rog
2003-07-07 21:28                 ` boyd, rounin
2003-07-07 20:54             ` Geoff Collyer
2003-07-09  2:07           ` William Josephson
2003-07-07 15:48         ` rob pike, esq.
2003-07-07 15:58           ` Jack Johnson
2003-07-08  8:32           ` Douglas A. Gwyn
2003-07-08 10:30             ` boyd, rounin
2003-07-08 11:09               ` matt
2003-07-08 11:36                 ` Dan Cross
2003-07-08 12:12                   ` boyd, rounin
2003-07-08 14:14                     ` ron minnich
2003-07-08 17:42                 ` chris
2003-07-08 20:19                   ` matt
2003-07-08 20:41                     ` boyd, rounin
2003-07-09 14:58                       ` rog
2003-07-09 19:42                         ` boyd, rounin
2003-07-10 12:30                           ` rog
2003-07-08 22:09                   ` ron minnich
2003-07-08 22:19                     ` Dan Cross
2003-07-09  1:27                       ` ron minnich

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='00ce01c3401a$45a9f740$d2944251@insultant.net' \
    --to=boyd@insultant.net \
    --cc=9fans@cse.psu.edu \
    /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).