We added two (library) calls readf and writef that perform file I/O besides resolving the name. We found ourselves calling them a lot, because in many cases it's very convenient. They would be an opportunity to "batch" walk/open/read(s)/clunk, which happen a lot. However, this would require changing the kernel (even more than we did for Plan B).
I think the man page is at http://planb.lsub.org/magic/man2html/2/readf We would be very interested on implementing this change for Plan 9 because we found that the main problem we have in Plan B is the latency accessing the various file servers, because of the addition of the individual RPC turn around times. Any thought on this? On 8/30/05, Dave Eckhardt <[EMAIL PROTECTED]> wrote: > > 'Tailcall optimizations' for filesystems with other mounted > > filesystems > > In Plan 9 all mounts are done at the client side, so this > wouldn't be an optimization--it's the only case. > > > * Macro messages > > Lightweight clients (such as microcontrollers) that communicate > > with a fileserver using 9P protocol over flaky radio connections > > would benefit from being able to compose several messages (eg: > > OPEN+READ+CLUNK) together a a single macro packet. > > 9P runs over TCP, so I don't think there's a packet-boundary > problem here. Getting a client to send the three messages > at once would seem to be the problem, since at present the > open() system call won't complete until the 9P message gets > its reply... there isn't an open()+read()+close() system > call. And you'd probably need to reinvent or clone existing > work on batch RPC's to do things like fill the result of the > OPEN into the subsequent READ request. > > > Also if in most cases, the number of operations performed > > during the time a file is open are small, it limits the number > > of open files and corresponding the state that needs to be > > stored for fids. > > Collecting or finding somebody else's data on that "if" might > be a good first step. > > Dave Eckhardt >
