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.xenproject.org (lists.xenproject.org [192.237.175.120]) (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 6DF4EC61DD6 for ; Wed, 2 Sep 2026 15:07:55 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.1406091.1639507 (Exim 4.92) (envelope-from ) id 1x1mYg-0002P8-7k; Wed, 02 Sep 2026 15:07:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406091.1639507; Wed, 02 Sep 2026 15:07:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1mYg-0002P1-4v; Wed, 02 Sep 2026 15:07:26 +0000 Received: by outflank-mailman (input) for mailman id 1406091; Wed, 02 Sep 2026 15:07:24 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1mYe-0002Ok-FX for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 15:07:24 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x1mYc-001wTX-0I; Wed, 02 Sep 2026 15:07:21 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x1mYb-00HXXU-1d; Wed, 02 Sep 2026 15:07:21 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=7uwt6EZj2ufEAQ5KMI1zSwIM5I80XSBcrup2qjUBGzM=; b=4S1XARDoDs5iVViRDhS2Xj4Ahi bDTV8PllfX8z+JCY3XNpNF81L1LGKydYbJotpYrngA1Br/8A8fea3P3ZgRo+cDcMDIQ5gAse9H/zp TJ20iuGIXV1TGYyGox6W3z/s0Wahrs6JExHKvMEywGgaTH94o87wM6mKQyKa0cAhxH74=; Date: Wed, 2 Sep 2026 17:07:16 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel Subject: Re: [PATCH 13/14] passthrough/PCI: rework (s,b,d,f) init of struct pci_dev Message-ID: References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> <52dcd7cd-52db-4b59-90ef-f7cde79cf5bc@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <52dcd7cd-52db-4b59-90ef-f7cde79cf5bc@suse.com> On Wed, Sep 02, 2026 at 02:53:58PM +0200, Jan Beulich wrote: > On 02.09.2026 14:44, Roger Pau Monné wrote: > > On Wed, Sep 02, 2026 at 08:36:27AM +0200, Jan Beulich wrote: > >> Right now we're casting away const-ness, to initialize the individual > >> elements despite the field(s) being declared const. Eclair validly > >> recognizes this as a Misra rule 11.8 violation. Hide this by switching to > >> the use of memcpy(), deriving the destination address from the (mutable) > >> struct pci_dev * which we hold in hands. > >> > >> No functional change intended. > >> > >> Signed-off-by: Jan Beulich > >> --- > >> Subsequently we may want to further leverage the sbdf local variable we > >> now have in the function. Yet of course the primary question is: Is this > >> an okay game to play in the first place? > > > > I've wondered the same, while this might be obfuscated enough for > > Eclair to complain, aren't we still violating the spirit of the rule? > > We do, but what do you do without dropping that "const" (which I'd really > like to keep), and without C++ concepts of initialization? Is it possible to "tag" this with a comment? Noting we are aware of the MISRA violation, but the result of the field being const outweigh the violation. At the end the memcpy() is also a violation, and hence is likely to also be flagged by Eclair in the future - it might be best to simply come clean and accept we have an intentional violation here. Thanks, Roger.