> This probably also means that Read returns in
> most cases less bytes than requested, just as much as needed for the
> current line up to \n. The server likely has to keep some information
> like the next read-offset expected, and the next line number, so that it
> can check whether the next read-request actually asks for the next line
> -- if it doesn't ignore seek/offsets at all, which also seems practicable.
You cannot do this, the usual idiom is that if read returns less
than the app expected this is treated as EOF. in my library the low level
function generates line at a time data, the library then performs multiple
reads to satisfy the apps read request filling its buffer and rembembering
the partial line for the next read request.
> I suppose this is adequate for control files waiting for commands. One
> can leave the fd open, and send one line after the other as needed.
I don't generally find this is nescessary, the fileserver/device driver holds
internal state so multiple writes mearly modify this state, thusly:
echo 'cts=1' > /dev/uart/ctl
echo 'baud=115200' > /dev/uart/ctl
We get a real win using the everything is a file idea in embedded as most of
our products
contain multiple PCBs and each PCB has a CPU (to load its xilinxes if nothing
else).
Given the remote file protocol running over a a couple of wires (the link layer
distantly related to datakit) we can monitor any cpu from any other cpu and
upgrade all flash files from the cpu that has ethernet.
Its a shame that we didn't have the guts and skill to make it
real plan9 from the begining - hindsignt is a wonderful thing.
-Steve
