From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Mon, 11 Jul 2005 16:13:26 -0500 From: Eric Van Hensbergen To: "Ronald G. Minnich" Subject: Re: [9fans] 8c question In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: Cc: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Topicbox-Message-UUID: 644bf2b6-ead0-11e9-9d60-3106f5b1d025 On 7/11/05, Ronald G. Minnich wrote: >=20 >=20 > On Mon, 11 Jul 2005, Eric Van Hensbergen wrote: >=20 > > But I thought that was the whole point - to convince them to use 9P for > > resource sharing versus the current stuff. Using 9P for transport alon= e > > just doesn't make sense to me -- let's sell them the whole enchilada. >=20 > you'll lose on the performance front. I'd still like to be able to walk t= o > a resource in the kernel and get a channel for it, and then use channel > reads and writes in the kernel to write the fifo queues. > With the new v9fs 2.1 server architecture, I should be able to go zero copy all the way and match their performance -- at least that's the plan. >=20 > Right now, you use a dedicated driver (which is how you name it -- you > know the driver to use) and drive the fifo queues. >=20 I know, I think that sucks. No reason this can't be unified. The performance sensative bits are always reads and writes -- if you can avoid copies, and I think we can -- particularly over a shared memory interface, then you should have equivilent performance -- just in a unified, easy to manage wrapper -- plus we'll have built in fail-over semantics for certain resources with Gorka's new recover stuff. -eric