From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCHv4 1/6] qemu/virtio: move features to an inline function Date: Mon, 02 Nov 2009 16:33:53 -0600 Message-ID: <4AEF5E51.80101@codemonkey.ws> References: <20091102222329.GB15153@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: avi@redhat.com, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org, gregory.haskins@gmail.com To: "Michael S. Tsirkin" Return-path: Received: from mail-qy0-f174.google.com ([209.85.221.174]:63860 "EHLO mail-qy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757151AbZKBWdw (ORCPT ); Mon, 2 Nov 2009 17:33:52 -0500 Received: by qyk4 with SMTP id 4so2680896qyk.33 for ; Mon, 02 Nov 2009 14:33:56 -0800 (PST) In-Reply-To: <20091102222329.GB15153@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. In particular, for vhost, we do not want to report to > guest bits not supported by kernel backend. Move the common bits from > virtio-pci to an inline function and let each device call it. > > No functional changes. > This is a layering violation. There are transport specific features and device specific features. The virtio-net device should have no knowledge or nack'ing ability for transport features. If you need to change transport features, it suggests you're modeling things incorrectly and should be supplying an alternative transport implementation. Regards, Anthony Liguori