From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH 0 of 9 RFC] blktap3: Introduce a small subset of blktap3 files Date: Thu, 29 Nov 2012 15:10:48 +0000 Message-ID: <1354201848.6269.12.camel@zakaz.uk.xensource.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Thanos Makatos Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Fri, 2012-11-16 at 18:25 +0000, Thanos Makatos wrote: > blktap3 is a disk backend driver. It is based on blktap2 but does not require > the blktap/blkback kernel modules as it allows tapdisk to talk directly to > blkfront. This primarily simplifies maintenance, and _may_ lead to performance > improvements. This patch series introduces a small subset of files required by > blktap3. blktap3 is based on a blktap2 fork maintained mostly by Citrix (it > lives in github), so these changes are also imported, apart from the blktap3 > ones. Sorry it took so long to look at this series, it generally looks good, thanks. I made a couple of minor comments on some patches and I noticed that I agreed with many of your TODOs. Can you list explicitly what is in the patch, I think it's the central dispatcher/ctl daemon, which spawns the tapdisk processes on demand, but not the tapdisk process itself? It might also be useful to give a high level overview of the architecture. Could you enumerate what the moving parts are and how they fit together? For example, I think, but I'm guessing a bit, that there is a daemon which watches xenstore and spawns processes on demand, is that right? Is that daemon called "tap-ctl" There is also an RPC mechanism for talking to either that daemon or the individual tapdisk process and a library for clients to speak it? This is unix domain socket based or something else? Ian.