From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MaagS-0004GZ-LB
	for qemu-devel@nongnu.org; Mon, 10 Aug 2009 15:37:28 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MaagO-0004Fk-DF
	for qemu-devel@nongnu.org; Mon, 10 Aug 2009 15:37:28 -0400
Received: from [199.232.76.173] (port=37301 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MaagO-0004Fb-5K
	for qemu-devel@nongnu.org; Mon, 10 Aug 2009 15:37:24 -0400
Received: from mail-gx0-f220.google.com ([209.85.217.220]:42372)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1MaagN-0006Bf-OR
	for qemu-devel@nongnu.org; Mon, 10 Aug 2009 15:37:23 -0400
Received: by gxk20 with SMTP id 20so10230067gxk.10
	for <qemu-devel@nongnu.org>; Mon, 10 Aug 2009 12:37:22 -0700 (PDT)
Message-ID: <4A8076F0.5050700@codemonkey.ws>
Date: Mon, 10 Aug 2009 14:37:20 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
References: <20090810192809.GA16800@redhat.com>
In-Reply-To: <20090810192809.GA16800@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH] qemu/virtio: move features to an inline
	function
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: rusty@rustcorp.com.au, qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org

Michael S. Tsirkin wrote:
> devices should have the final say over which virtio features they
> support. E.g. indirect entries may or may not make sense in the context
> of virtio-console.  Move the common bits from virtio-pci to an inline
> function and let each device call it.
>   

What drove this in vhost?

Normally, the common features are transport features and the devices 
should have absolutely no knowledge of transport feature (since they're 
transport dependent).

IOW, VIRTIO_RING_F_INDIRECT_DESC is meaningless to virtio-console 
because virtio-console has no idea what the ring implementation is that 
it sits on top of.

Regards,

Anthony Liguori