From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 10 Apr 1998 18:16:58 -0500 From: G. David Butler gdb@dbSystems.com Subject: [9fans] allowing long file names with a space too Topicbox-Message-UUID: 74dca768-eac8-11e9-9e20-41e7f4b1d025 Message-ID: <19980410231658.xlmIeo6n56cVHt7nv1RYmd_pETurKsTDjgYA2SLIpPw@z> From: "G. David Butler" >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