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 046D7C433FE for ; Tue, 8 Nov 2022 17:53:29 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1osSmD-0001YP-JM; Tue, 08 Nov 2022 12:52:45 -0500 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 1osSmC-0001Y7-N8 for qemu-devel@nongnu.org; Tue, 08 Nov 2022 12:52:44 -0500 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 1osSmA-0003wI-NL for qemu-devel@nongnu.org; Tue, 08 Nov 2022 12:52:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1667929961; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=ZNFEodqGsPt2rgjQ3oI5FYPKLLvS2XUb7c2Bxv+eIJE=; b=ej8m4aGvDHtivJpCGghss7mufPK4BTTwgfK1XSD5a5q9Hj9ESkESbLOW8ip4oasSrqA78c o3PfyFOcIPJ9hWhOONrb4NcPnbSHDFqYHYXNMEz/MIXJT4DI6kSe0bQyqPCtXETmjm55I/ mmi3orE+/ZbzmSVruTiPvhN6xPFp1/0= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-356-MMLRSb9OPeuroRy5caXfYQ-1; Tue, 08 Nov 2022 12:52:32 -0500 X-MC-Unique: MMLRSb9OPeuroRy5caXfYQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 3E9C48339B4; Tue, 8 Nov 2022 17:52:32 +0000 (UTC) Received: from redhat.com (unknown [10.33.36.150]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D9F7D140EBF3; Tue, 8 Nov 2022 17:52:30 +0000 (UTC) Date: Tue, 8 Nov 2022 17:52:27 +0000 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Peter Maydell Cc: QEMU Developers , Paolo Bonzini , Eduardo Habkost , Alex =?utf-8?Q?Benn=C3=A9e?= Subject: Re: QOM: should you be able to cast from an interface class to the concrete class? Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.2.7 (2022-08-07) X-Scanned-By: MIMEDefang 3.1 on 10.11.54.7 Received-SPF: pass client-ip=170.10.133.124; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org On Tue, Nov 08, 2022 at 04:01:56PM +0000, Peter Maydell wrote: > Hi; in the QOM model, are you supposed to be able to cast from > an interface class to the concrete class that is implementing it? > > To give a specific example, if I have a ResettableClass *rc > should I be able to do DeviceClass *dc = DEVICE_CLASS(rc); > (assuming that the rc I have is actually from a DeviceClass) ? > > If I'm reading the code correctly, at the moment this isn't possible: > object_class_dynamic_cast() has code for "if the class we're > casting from implements interfaces and the class we're casting to > is an interface, then look through the list of interfaces to > see if we should be returning the class pointer from the interface > list", which means you can cast from the concrete class to the > interface class. But there's no code there to say "if the class > we're casting from is an interface, try the concrete class". > > As far as I can see we do actually record the information we need > to do this -- InterfaceClass has a field concrete_class that points > to the concrete class that's implementing it. But this field is > currently only written, never read. > > Should we: > (a) support casting from the interface class back to the concrete > class, by adding some extra code in object_class_dynamic_cast(), or > (b) decide that that isn't something we should be wanting to do, > and remove the dead concrete_class struct field ? My rule of thumb would be, if it is possible with GObject, then it is reasonable to want it in QOM, and indeed you can cast from an interface in GObject, back to the concrete type that has implemented it. So I'd go for (a). With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|