From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <0d0b92a3240f0dc23cf188e590ec321e@collyer.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Van Jacobsen's network stack restructure
Date: Thu,  2 Feb 2006 16:24:25 -0800
From: geoff@collyer.net
In-Reply-To: <4f9b14f1f51c8780568bd394ad4c8918@quanstro.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: f01969d6-ead0-11e9-9d60-3106f5b1d025

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.