Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751378AbdCIDHu (ORCPT ); Wed, 8 Mar 2017 22:07:50 -0500 Received: from smtp.ctxuk.citrix.com ([185.25.65.24]:36386 "EHLO SMTP.EU.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750728AbdCIDHs (ORCPT ); Wed, 8 Mar 2017 22:07:48 -0500 X-IronPort-AV: E=Sophos;i="5.36,266,1486425600"; d="scan'208";a="42129506" Date: Thu, 9 Mar 2017 12:02:32 +0900 From: Roger Pau =?iso-8859-1?Q?Monn=E9?= To: Stefano Stabellini CC: , , , , , , , Subject: Re: [Xen-devel] [PATCH 0/7] Xen transport for 9pfs frontend driver Message-ID: <20170309030232.fdmri3ovrhv4mrjp@MacBook-Pro-de-Roger.local> References: <20170307163859.womjnoeha7wj23ka@MacBook-Pro-de-Roger.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170306 (1.8.0) X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1617 Lines: 36 On Tue, Mar 07, 2017 at 10:27:05AM -0800, Stefano Stabellini wrote: > On Tue, 7 Mar 2017, Roger Pau Monn? wrote: > > On Mon, Mar 06, 2017 at 12:00:41PM -0800, Stefano Stabellini wrote: > > > Hi all, > > > > > > This patch series implements a new transport for 9pfs, aimed at Xen > > > systems. > > > > > > The transport is based on a traditional Xen frontend and backend drivers > > > pair. This patch series implements the frontend, which typically runs in > > > a regular unprivileged guest. > > > > > > I'll follow up with another series that implements the backend in > > > userspace in QEMU, which typically runs in Dom0 (but could also run in > > > a another guest). > > > > > > The frontend complies to the Xen transport for 9pfs specification > > > version 1, available here: > > > > > > http://xenbits.xen.org/gitweb/?p=xen.git;a=blob_plain;f=docs/misc/9pfs.markdown;hb=HEAD > > > > Kind of tangential to this series, but maybe it would make sense to implement > > this transport in a fuse based 9pfs driver? I see there are already several > > fuse-9pfs implementations around. Something for a GSoC/Outreach project? > > Sure. Additionally, with open source frontends and backends already > available, it should be easier to code. I am happy to co-mentor the > project with you, if you feel like it. I don't mind co-mentoring it, so far I haven't got lucky with any of my other GSoC projects, but I don't know anything about 9pfs or fuse :). This also has the difficulty that neither you not me is a member of any of the 9pfs-fuse projects, so it might be hard to get the changes upstream. Roger.