From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Mon, 11 Jul 2005 15:35:01 -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: 64168d24-ead0-11e9-9d60-3106f5b1d025 On 7/11/05, Ronald G. Minnich wrote: >=20 >=20 > On Mon, 11 Jul 2005, Eric Van Hensbergen wrote: >=20 > > Oi - my gut is that this sounds wrong. What would make more sense is > > for #X to look more like devsrv, with the virtual channels representing= . > > Then you could mount /dev/xen/dom0 /n/dom0 and then bind as you like. >=20 > Can those channels correspond to the current channels that talk via fifo > queue to in-kernel linux devices (the so-called backend devices)? >=20 Yeah, well -- sorta. You probably have a better understanding of the way Xen does stuff than I do. I guess in the current context that is exactly what they would correspond to, but in a 9P-based world, you would only need a single channel. You would mount the exported private namespace containing the devices allocated to your partition over that channel (instead of individually mounting disk, network, etc.) I haven't fully thought through how this would extend across a cluster yet - but I think a bridging I/O partition would "just work". Not sure if I would have "cluster" channels or whether the I/O partition would mount from other servers and then re-export the resources. -eric