From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:54908)
	by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <hch@lst.de>)
	id 1Zze1I-0000fM-PK
	for qemu-devel@nongnu.org; Fri, 20 Nov 2015 00:14:01 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <hch@lst.de>) id 1Zze1F-0000bC-Jx
	for qemu-devel@nongnu.org; Fri, 20 Nov 2015 00:14:00 -0500
Received: from verein.lst.de ([213.95.11.211]:36458 helo=newverein.lst.de)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <hch@lst.de>)
	id 1Zze1F-0000aO-Dv
	for qemu-devel@nongnu.org; Fri, 20 Nov 2015 00:13:57 -0500
Date: Fri, 20 Nov 2015 06:13:55 +0100
From: Christoph Hellwig <hch@lst.de>
Message-ID: <20151120051355.GA19405@lst.de>
References: <1447978868-17138-1-git-send-email-mlin@kernel.org>
	<1447978868-17138-5-git-send-email-mlin@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1447978868-17138-5-git-send-email-mlin@kernel.org>
Subject: Re: [Qemu-devel] [RFC PATCH 4/9] nvmet: add a controller "start"
	hook
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Ming Lin <mlin@kernel.org>
Cc: Ming Lin <ming.l@ssi.samsung.com>, qemu-devel@nongnu.org, "Nicholas A. Bellinger" <nab@linux-iscsi.org>, virtualization@lists.linux-foundation.org, linux-nvme@lists.infradead.org, Christoph Hellwig <hch@lst.de>

On Thu, Nov 19, 2015 at 04:21:03PM -0800, Ming Lin wrote:
>  #define NVMET_SUBSYS_NAME_LEN		256
>  	char			subsys_name[NVMET_SUBSYS_NAME_LEN];
> +
> +	void			*opaque;
> +	void			(*start)(void *);
>  };

Why can't vhost use container_of to get at the containing structure
similar to what the loop driver does?

In addition I think we'll eventually need an ops structure here,
but I can take care of that later.