9P2000.s vs 9P2020 vs. ? (Was Re: [9front] Slow cp, support for 9P2000.s)

[Romano <unobe@cpan.org>]

Since there's no existing discussion I can see, and IRC isn't meant for searching for answers to questions, is there anyone willing to summarize the state of solving problems like streaming for 9P?

If Aiju remembers correctly, there were two things where 9P2000.s was found wanting:
1) it breaks the syscall interface; and
2) it forces 9P to run over TCP.

FWIW, I finally finished reading through all of John's thesis, rather than just skimming, and I think John did a nice review of the previous work done in this area and presenting why he chose the solution he did.  His solution used TCP, but from his write-up, I don't see a technical reason why another transport protocol[1] could not be used. That would leave only breaking the syscall interface.

Does breaking the syscall interface mean that it's merely adding a syscall? Or does it mean something else?

Right now hget(1) is an rc script that uses webfs(4).  So if I'm at a terminal far away and am using webfs provided by the server I'm connected to, hget would be slow for a large file because the file would be transferred over 9P. It's no better than Plan 9's implementation, but no worse either.

[1] https://en.wikipedia.org/wiki/Category:Transport_layer_protocols