From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW39a-0001iP-9b for qemu-devel@nongnu.org; Mon, 22 Sep 2014 08:55:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XW39R-0004uk-6C for qemu-devel@nongnu.org; Mon, 22 Sep 2014 08:55:42 -0400 Received: from mail-wg0-x230.google.com ([2a00:1450:400c:c00::230]:64968) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW39Q-0004u6-Mk for qemu-devel@nongnu.org; Mon, 22 Sep 2014 08:55:32 -0400 Received: by mail-wg0-f48.google.com with SMTP id z12so2633105wgg.31 for ; Mon, 22 Sep 2014 05:55:26 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <54201C35.1090502@redhat.com> Date: Mon, 22 Sep 2014 14:55:17 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1410792279-2488-1-git-send-email-arei.gonglei@huawei.com> <20140922083421.GA13006@redhat.com> <541FE889.3050209@redhat.com> <33183CC9F5247A488A2544077AF1902086DD90B3@SZXEMA503-MBS.china.huawei.com> <541FF3F9.5060705@redhat.com> <33183CC9F5247A488A2544077AF1902086DD915A@SZXEMA503-MBS.china.huawei.com> <542010CE.3010209@redhat.com> <20140922123419.GA7992@redhat.com> In-Reply-To: <20140922123419.GA7992@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 0/3] Fix confused output for alias properties List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: "Huangweidong (C)" , "stefanha@redhat.com" , "qemu-devel@nongnu.org" , "agraf@suse.de" , "Gonglei (Arei)" , "aliguori@amazon.com" , "Huangpeng (Peter)" , "lcapitulino@redhat.com" Il 22/09/2014 14:34, Michael S. Tsirkin ha scritto: > On Mon, Sep 22, 2014 at 02:06:38PM +0200, Paolo Bonzini wrote: >> Il 22/09/2014 13:22, Gonglei (Arei) ha scritto: >>>> This doesn't change the fact that ObjectProperty is a generic struct, >>>> and adding alias-specific fields there is wrong. >>> >>> OK, Maybe I should find other ways to attach this purpose and >>> avoid layering violation. Thanks! >> >> Unfortunately I cannot think of any. >> >> We could add a description field to ObjectProperty, and replace >> legacy_name with a description. The output then would be >> >> virtio-blk.drive=str (drive) >> That's a bit hackish, but perhaps it would be good enough for mst and >> Markus? > > I would just drop "str" and replace it with drive. In the above example, the format would be CLASS.PROPERTY=TYPE (DESCRIPTION) where I just put "drive" as the description to resemble the old output. You cannot just have foo.drive=drive because the type is *not* "drive", it's "str" (if anything, we could make it link which does not really show the connection between BlockBackend and -drive). The problem is that "drive" as the type (the legacy_name) is simply not available for the virtio-blk-pci.drive property. It's hidden beneath an opaque pointer. Gonglei's patches were adding fields to ObjectProperty just to avoid visiting that opaque pointer, which I consider a layering violation. > I seems to convey zero information. > Description should be something more informative, e.g. > (ID of a drive to use as a backend) That would of course be fine too. The problem is then that we have 644 properties (DEFINE_PROP_* macro invocations) that someone must add a description to. > Help for -device could add "Must match ID of a -drive option". > Help for device HMP command could add "Must match ID of a drive command." You are turning a bug that nobody noticed until now, and that really doesn't break anything, into a month or more worth of work. Paolo