From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <9bd1c348b487ab7f85af250e76175753@hamnavoe.com>
To: 9fans@9fans.net
From: Richard Miller <9fans@hamnavoe.com>
Date: Fri, 16 Mar 2012 17:04:00 +0000
In-Reply-To: <CA+Tk8fzHcHvd-yMfwVXSC7hpH-AsA1ocYhe0m+K7mPar=HF-sA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Regarding 9p based "protocols" message framing
Topicbox-Message-UUID: 6a059eb2-ead7-11e9-9d60-3106f5b1d025

>     * the tools must be aware of this mapping between 1 request == 1
> write operation; thus if for example my request would be composed of
> multiple lines, and I use `cat >./some-file` as an "interface"; then
> `cat` would read one line and immediately send it as an individual
> write operation which of course is not respecting the "protocol" built
> ontop of 9p;

In general, control requests are not multiple lines (I presume by "line"
you mean a string of characters delimited by '\n').  As you say, each
request must be presented in a single 9p message, and this fits well
with the guarantee that 9p read/write messages are atomic [provided
tbe length is <= iounit].  The first example in 2.6 of /sys/doc/auth is
misleading -- if you try to do literally what it says:

	% cd /mnt/factotum
	% cat >ctl
	key dom=bell-labs.com proto=p9sk1 user=gre
		!password='don''t tell'
	key proto=apop server=x.y.com user=gre
		!password='bite me'
	^D

you'll find you get a write error after the first line; each 'key'
command actually has to be sent as a single write.  You can't even
get it to accept multiple lines in one write:

	term% echo 'key dom=bell-labs.com proto=p9sk1 user=gre
			!password=bite-me' >/mnt/factotum/ctl
	echo: write error: multiline write not allowed

In my experience, sending control requests as single atomic writes
is a natural way to work.  With failed requests communicated as
write errors, this makes it simple to match the error status with
the request.

Multiline responses are somewhat more common, and there is some
inconsistency in whether responses also need to be read as a single
atomic operation.  This can make it tricky, for example, to use the
read(1) command -- which reads one char at a time -- in a script
dealing with a device control interface.

For example, this loop works:
	</dev/irqalloc while (x=`{read}) echo $x
but this doesn't:
	</dev/ioalloc while (x=`{read}) echo $x