No, I think Charles has a good point about TCAM. In the brave new VJ world, how does a process know if its standard input (file descriptor 0) is a normal descriptor or a magic VJ-channel descriptor? It has to know in order to know if it should call read(0, ...) or read_vj_chan(0, ...), and that in turn returns us to RSX-11 land: different system calls for different kinds of files.
One could try to minimise the disruption by having a tcp file server process that reads and writes VJ-channels (and only that process would read and write tcp VJ-channels), does tcp processing, and reads and writes ordinary file descriptors to its clients, but that hurts the attempt to minimise copying by using VJ channels. Actually you might have to have a tcp file server process (or equivalent) since tcp might want to keep state across all concurrent tcp connections. Using lock-free data structures might be worth pursuing. I worry a little about letting user processes diddle tcp headers directly. I don't immediately see a security hazard, but I can't swear that there isn't one.
