From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <468D8253.9030400@wmipf.in-berlin.de>
Date: Fri,  6 Jul 2007 01:44:19 +0200
From: =?UTF-8?B?TWljaGFlbCBUZWljaGdyw6RiZXI=?= <mt@wmipf.in-berlin.de>
User-Agent: Icedove 1.5.0.8 (X11/20061208)
MIME-Version: 1.0
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] implementing 9p read
References: <8d88287934ff066cf767d5d1e024cf94@quintile.net>
In-Reply-To: <8d88287934ff066cf767d5d1e024cf94@quintile.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 91b87e20-ead2-11e9-9d60-3106f5b1d025

> line at a time - the library assembles the lines into the requested
> buffer's worth

Nice - this way you may easily generate quite large files using a buffer
covering just one line. 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.

> writing files can be flagged smilarly:
> 
> line at a time - newlines and leading and trailing whitespace
> stripped

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.

One thing I like about the idea using 9p even in smaller systems is,
that you can define one file to be something like a "serial terminal".
If one has a lot of such embedded devices connected to a network, one
can easily have a "command line" for each of them without the need to
connect each to a real serial port.

Michael