Re: [9fans] Rstat needs three size fields?

Re: [9fans] Rstat needs three size fields?

[boyd, rounin]

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'.

[9fans] Python?

[Jack Johnson]

Anyone know what the status of Python is on Plan 9?  I'm wondering if
it's up to handling something like Zope.

I've also been checking out wxWindows/wxPython a little and started
wondering what a wxWindows port to rio would look like
( http://www.wxwindows.org/ ).

-Jack

Re: [9fans] Python?

[boyd, rounin]

> Anyone know what the status of Python is on Plan 9?  I'm wondering if
> it's up to handling something like Zope.

the zope dopes, therein lies a story ...