From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <8d88287934ff066cf767d5d1e024cf94@quintile.net>
From: "Steve Simon" <steve@quintile.net>
Date: Thu,  5 Jul 2007 20:14:09 +0100
To: 9fans@cse.psu.edu
Subject: Re: [9fans] implementing 9p read
In-Reply-To: <84c03de05d2626f54ae08464b2933408@plan9.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Topicbox-Message-UUID: 91a60830-ead2-11e9-9d60-3106f5b1d025

> I don't see how this can be helped other than keeping buffers allocated
> on a per open-file basis =E2=80=94 and that would be overkill.

We run an embdeed os at work for which we stole many ideas from plan9.

It has a lib9pfile like library to make writing servers easier.
Generally it uses an array of initialised C structures to define the
hierarchy you want to serve, which contains functions to generate the
contents of these files; Each file also has an associated read and write
flag word. Files can be read:

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

	file at a time - contents generated in malloced memory on open
		and freed on close

	raw access - requests passed direct to underlying function

writing files can be flagged smilarly:

	line at a time - newlines and leading and trailing whitespace stripped

	file at a time - application specific function called only on close

	raw - as above.

This has been useful and I have thought about writing a similar library f=
or
plan9 but have not done so yet, its difficult to decide what is useful of=
ten
enough to libraryise and what is just "nice to have".

-Steve