From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 10.80.166.35 with SMTP id d32csp1498567edc; Fri, 21 Oct 2016 11:26:26 -0700 (PDT) X-Received: by 10.55.120.193 with SMTP id t184mr2488201qkc.155.1477074386419; Fri, 21 Oct 2016 11:26:26 -0700 (PDT) Return-Path: Received: from lists.gnu.org (lists.gnu.org. [2001:4830:134:3::11]) by mx.google.com with ESMTPS id 42si2692057qky.239.2016.10.21.11.26.26 for (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 21 Oct 2016 11:26:26 -0700 (PDT) Received-SPF: pass (google.com: domain of qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org designates 2001:4830:134:3::11 as permitted sender) client-ip=2001:4830:134:3::11; Authentication-Results: mx.google.com; spf=pass (google.com: domain of qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org designates 2001:4830:134:3::11 as permitted sender) smtp.mailfrom=qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org Received: from localhost ([::1]:33723 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bxeWP-0002Z1-Sp for alex.bennee@linaro.org; Fri, 21 Oct 2016 14:26:25 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37300) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bxeWK-0002Yv-8U for qemu-arm@nongnu.org; Fri, 21 Oct 2016 14:26:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bxeWH-0002YM-3x for qemu-arm@nongnu.org; Fri, 21 Oct 2016 14:26:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42094) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bxeWG-0002XI-Sg; Fri, 21 Oct 2016 14:26:17 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DAA284E4C6; Fri, 21 Oct 2016 18:26:13 +0000 (UTC) Received: from blackfin.pond.sub.org (ovpn-116-73.ams2.redhat.com [10.36.116.73]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9LIQAdO021959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 21 Oct 2016 14:26:11 -0400 Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id A1EDB1138645; Fri, 21 Oct 2016 20:26:09 +0200 (CEST) From: Markus Armbruster To: Peter Maydell References: <20161018130007.k7hhxovkxiqiumfj@kamzik.brq.redhat.com> <20161018131829.GQ3275@thinpad.lan.raisama.net> <20161018142247.55d4aymduofvhy3r@kamzik.brq.redhat.com> <20161018152207.GZ3275@thinpad.lan.raisama.net> <20161018162202.pmui5rv3va7ubcrv@kamzik.brq.redhat.com> <20161018175737.3biqteztu3esvaaq@kamzik.brq.redhat.com> <20161018184532.GC3275@thinpad.lan.raisama.net> <20161018204937.GB5057@thinpad.lan.raisama.net> Date: Fri, 21 Oct 2016 20:26:09 +0200 In-Reply-To: (Peter Maydell's message of "Tue, 18 Oct 2016 22:08:21 +0100") Message-ID: <87d1iteeym.fsf@dusky.pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 21 Oct 2016 18:26:15 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: Re: [Qemu-arm] [Qemu-devel] QOM properties vs C functions/fields (was Re: [PATCH v3 2/3] exec: rename cpu_exec_init() as cpu_exec_realizefn()) X-BeenThere: qemu-arm@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Anthony Green , QEMU Developers , Max Filippov , Greg Ungerer , Guan Xuetao , Chen Gang , Jia Liu , Alexander Graf , Bharata B Rao , David Gibson , Artyom Tarasenko , Laurent Vivier , Andrew Jones , Eduardo Habkost , Greg Kurz , qemu-arm , Igor Mammedov , Richard Henderson , Matthew Rosato , Bastian Koppelmann , Michael Walle , "qemu-ppc@nongnu.org" , Paolo Bonzini , Aurelien Jarno Errors-To: qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org Sender: "Qemu-arm" X-TUID: G/9r2g0A+UgR Peter Maydell writes: > On 18 October 2016 at 21:49, Eduardo Habkost wrote: >> On Tue, Oct 18, 2016 at 09:30:01PM +0100, Peter Maydell wrote: >>> Lots of stuff in a device's C struct is strictly internal >>> and not to be messed with. I thought that QOM properties >>> were essentially how a device defined its public (and >>> typically settable-only-once) config knobs. QOM properties >>> shouldn't be user-facing (read: stable, required to be >>> backwards-compatible) interface in general because >>> we don't really want to tie ourselves down that much. >>> In fact almost all our QOM objects are not usefully >>> user-facing at all. >> >> This interpretation surprises me, because it is the opposite of >> what I have seen us doing. Most of our QOM objects and properties >> are user-visible and user-configurable using -global, -device, >> -object, or qom-set (and probably other QMP commands). > > Most of the devices I deal with are not and never will > be sensibly usable with -device. Exposing wiring up > of IRQ and GPIO lines or MMIO regions to the user is > never going to make sense. For x86 most devices are > probably pluggable (and usable with -device), but over > the whole source tree I think the embedded-style device > is in the majority. They're all still worth QOMifying > and having properties for the things board code wants > to modify, though. "Device not pluggable" does not imply "device has no configuration knobs a user may legitimately want to mess with". Plenty of onboard devices have such knobs. Right now, users configure these mostly via board-agnostic options like -serial. Anything that doesn't fit the mold can't be configured that way. However, A fully mature QOM as I envisage it would provide users access to QOM properties for onboard devices, too. Not with -device, obviously, but with qom-set and similar, as Eduardo said. If any of these properties are not for users, they should be marked as such. Just like for pluggable devices. Perhaps non-pluggable devices tend to have more "not for users" QOM properties than pluggable ones, I don't know. But that would be a *quantitative* difference, not a *qualitative* one. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37316) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bxeWN-0002Z0-3G for qemu-devel@nongnu.org; Fri, 21 Oct 2016 14:26:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bxeWM-0002ag-2k for qemu-devel@nongnu.org; Fri, 21 Oct 2016 14:26:23 -0400 From: Markus Armbruster References: <20161018130007.k7hhxovkxiqiumfj@kamzik.brq.redhat.com> <20161018131829.GQ3275@thinpad.lan.raisama.net> <20161018142247.55d4aymduofvhy3r@kamzik.brq.redhat.com> <20161018152207.GZ3275@thinpad.lan.raisama.net> <20161018162202.pmui5rv3va7ubcrv@kamzik.brq.redhat.com> <20161018175737.3biqteztu3esvaaq@kamzik.brq.redhat.com> <20161018184532.GC3275@thinpad.lan.raisama.net> <20161018204937.GB5057@thinpad.lan.raisama.net> Date: Fri, 21 Oct 2016 20:26:09 +0200 In-Reply-To: (Peter Maydell's message of "Tue, 18 Oct 2016 22:08:21 +0100") Message-ID: <87d1iteeym.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] QOM properties vs C functions/fields (was Re: [PATCH v3 2/3] exec: rename cpu_exec_init() as cpu_exec_realizefn()) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Eduardo Habkost , Anthony Green , QEMU Developers , Alexander Graf , Max Filippov , Greg Ungerer , "Edgar E . Iglesias" , Guan Xuetao , Jia Liu , Bharata B Rao , Richard Henderson , Artyom Tarasenko , Laurent Vivier , Andrew Jones , Chen Gang , Greg Kurz , qemu-arm , Paolo Bonzini , David Gibson , Matthew Rosato , Bastian Koppelmann , Michael Walle , "qemu-ppc@nongnu.org" , Igor Mammedov , Aurelien Jarno Peter Maydell writes: > On 18 October 2016 at 21:49, Eduardo Habkost wrote: >> On Tue, Oct 18, 2016 at 09:30:01PM +0100, Peter Maydell wrote: >>> Lots of stuff in a device's C struct is strictly internal >>> and not to be messed with. I thought that QOM properties >>> were essentially how a device defined its public (and >>> typically settable-only-once) config knobs. QOM properties >>> shouldn't be user-facing (read: stable, required to be >>> backwards-compatible) interface in general because >>> we don't really want to tie ourselves down that much. >>> In fact almost all our QOM objects are not usefully >>> user-facing at all. >> >> This interpretation surprises me, because it is the opposite of >> what I have seen us doing. Most of our QOM objects and properties >> are user-visible and user-configurable using -global, -device, >> -object, or qom-set (and probably other QMP commands). > > Most of the devices I deal with are not and never will > be sensibly usable with -device. Exposing wiring up > of IRQ and GPIO lines or MMIO regions to the user is > never going to make sense. For x86 most devices are > probably pluggable (and usable with -device), but over > the whole source tree I think the embedded-style device > is in the majority. They're all still worth QOMifying > and having properties for the things board code wants > to modify, though. "Device not pluggable" does not imply "device has no configuration knobs a user may legitimately want to mess with". Plenty of onboard devices have such knobs. Right now, users configure these mostly via board-agnostic options like -serial. Anything that doesn't fit the mold can't be configured that way. However, A fully mature QOM as I envisage it would provide users access to QOM properties for onboard devices, too. Not with -device, obviously, but with qom-set and similar, as Eduardo said. If any of these properties are not for users, they should be marked as such. Just like for pluggable devices. Perhaps non-pluggable devices tend to have more "not for users" QOM properties than pluggable ones, I don't know. But that would be a *quantitative* difference, not a *qualitative* one.