[9fans] allowing long file names with a space too

[G. David Butler gdb@dbSystems.com]

From: "G. David Butler" <gdb@dbSystems.com>

>NAMELEN = 28
>FNAMELEN = 64? 128? 256!?  Hell, might as well fix it now. 256.
>
>In that case the overhead for 9p now gets quite high given all
>the Twalks.  So how about a uchar length followed by data?  Makes
>sense.

Lets say that FNAMELEN = 256 then:

DIRLEN = 344

Tclwalk tag[2] fid[2] newfid[2] name[<=256]
Twalk tag[2] fid[2] name[<=256]
Tcreate tag[2] fid[2] name[<=256] perm[4] mode[1] [move name to the end?]
Rstat tag[2] fid[2] stat[<=344]
Twstat tag[2] fid[2] stat[<=344]

[why is there a pad[1] in Twrite and Rread?]

The idea is to only send the variable data in 9P, so the
"machine independent encoding" stays fixed length.  The mount
driver will do the "right thing".  In other words, since
names must terminate with a null '\0', in 9P there will only
be one.  It is the mnt driver's responsibility to transmit
the Twstat and receive Rstat and directory Tread/Twrite that way.

On directory read, the mount driver will have to muck with
the offsets since they must be 0 mod DIRLEN.  On Tread the offset
and count will be 0 mod DIRLEN but the server will respond with
the real count of the packet.  The mnt driver will expand the names
and set the offset for the channel so the next Tread will work.
This is permissable already (see devdirread() in /sys/src/9/port/dev.c
and the comment in /sys/src/9/port/sysfile.c).  I use it now to allow
efficient reads of the large directories on my file server by
eliminating the silly "count the filled slots" algorithm.  (You see,
only the mnt driver knows the proper offsets for the channel.)

We could add count[2] to the above messages, but I don't think
that is necessary.

It's too bad that Tcreate didn't have the name at the end, then the
resulting kernel would be backward compatable with existing servers. :-(

Comments?  (the ones that look like "your crazy" to /dev/null)

David Butler
gdb@dbSystems.com