From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9ECD3C25B76 for ; Tue, 11 Jun 2024 05:51:17 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sGuOW-0008UH-3R; Tue, 11 Jun 2024 01:50:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sGuOS-0008U4-Eo for qemu-devel@nongnu.org; Tue, 11 Jun 2024 01:50:04 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sGuOQ-0006eo-Uq for qemu-devel@nongnu.org; Tue, 11 Jun 2024 01:50:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1718085001; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lnTcopFK3YO3q+7LOZ8Vlb7WBNkuEX6akzGvfkE2WaY=; b=OxWtH/Gylq8OL6BOu7jgnsqKdc+8jTk94UmV98HSeFJt8tlE1hAXcXtvoU4Tm9wt91bjyO 9eim7p/gK0cvaRytZiitBU5MyOEwzt/6xW1F80R0Z7QK5lu7zHOe20MWAd1DnP7t7VtLh+ oG6atbljLiLSsDx1eOCfyrGAMPMYdLU= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-504-dLERJ0j3OtS6KgKfIrdRrQ-1; Tue, 11 Jun 2024 01:49:18 -0400 X-MC-Unique: dLERJ0j3OtS6KgKfIrdRrQ-1 Received: from mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 5E0B41956059; Tue, 11 Jun 2024 05:49:16 +0000 (UTC) Received: from blackfin.pond.sub.org (unknown [10.39.192.93]) by mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id E375A19560AA; Tue, 11 Jun 2024 05:49:14 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id B078421E681D; Tue, 11 Jun 2024 07:49:12 +0200 (CEST) From: Markus Armbruster To: Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= Cc: qemu-devel@nongnu.org, "Dr. David Alan Gilbert" , Mark Cave-Ayland , Daniel P . =?utf-8?Q?Berrang=C3=A9?= , qemu-ppc@nongnu.org, Paolo Bonzini , Eduardo Habkost , Peter Maydell Subject: Examining device state via monitor for debugging (was: [PATCH 0/2] hw/misc/mos6522: Do not open-code hmp_info_human_readable_text()) In-Reply-To: <20240610150758.2827-1-philmd@linaro.org> ("Philippe =?utf-8?Q?Mathieu-Daud=C3=A9=22's?= message of "Mon, 10 Jun 2024 17:07:56 +0200") References: <20240610150758.2827-1-philmd@linaro.org> Date: Tue, 11 Jun 2024 07:49:12 +0200 Message-ID: <87h6e0uizr.fsf@pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.0 on 10.30.177.40 Received-SPF: pass client-ip=170.10.133.124; envelope-from=armbru@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: 11 X-Spam_score: 1.1 X-Spam_bar: + X-Spam_report: (1.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.143, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Philippe Mathieu-Daud=C3=A9 writes: > Officialise the QMP command, use the existing > hmp_info_human_readable_text() helper. I'm not sure "officialise" is a word :) Taking a step back... "info via" and its new QMP counterpart x-query-mos6522-devices dump device state. I understand why examining device state via monitor can be useful for debugging. However, we have more than 2000 devices in the tree. Clearly, we don't want 2000 device state queries. Not even 100. Could we have more generic means instead? We could use QOM (read-only) properties to expose device state. If we use one QOM property per "thing", examining device state becomes quite tedious. Also, you'd have to stop the guest to get a consistent view, and adding lots of QOM properties bloats the code. If we use a single, object-valued property for the entire state, we get to define the objects in QAPI. Differently tedious, and bloats the generated code. We could use a single string-valued property. Too much of an abuse of QOM? We could add an optional "dump state for debugging" method to QOM, and have a single query command that calls it if present. Thoughts?