[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [XEN PATCH v2] x86/iommu_init: address a violation of MISRA C:2012 Rule 8.3
- To: Federico Serafini <federico.serafini@xxxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Thu, 2 Nov 2023 15:24:25 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=AGpJJNfEkHTNmP/I2gqqtBdgV/3ysAmfN2nToV2GzM0=; b=mgI7ocBPpiRgYjs1acf3qQNlhsRRvP6D6fPv3TAF8caQFX0m5VbNgQYR+VkZH4zYcaZe/ODiYTHoL28950FmzX4Fe2pkVKJqQTc+edWoAGVKUAs9q0FsO9taQW0HEspnSYt6V7dXVCDC13e5OeySiaq3CP9h+lME89qOyF4rGblouTbyPdVRTP2CfviK2kQh5CBswW1lFUiEVjZ1i1U6PiQBetSJ4BYbknFrj6nMu5Akvp5aPDvYdlXJNukvpmem9zaOq9ULJn7bKtT2xYyWzxVWTTRjIRe6SOgachxB5aP9QJePOVHjNy61vLSBrOn8ctBdnCGrWXmev9rTS+Si4A==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZJe2EuyNLLJe27D/a3bYuUd5/PczQuvGO/BOsM+ZjjizF5567AP/U+p//WfBiyQEfIyfwAx+CJHsw9aLhfspLHtR7lYXufYm1iRsqn1XTmO9ZjtCSGMpyPp1+kEjaXnfu9iOoXcT8JzkNtnig0VxK+BIXM0EAJw2u4sllBJZwIPKqQjBco8H8GxZltTvyRvAM+yrplOjOdLXuOy3gViaIJf/cds0fzz6grnBPvwPJ83BN6D5rLz1DHCQ3jfhzgPHpbbuNnfRlcae3LMe+VikJt+LYkqoZByCm9idm0vqxzUV1LRhrTDC41pILd5GHrYMv93SKO7wKupRGRwaruCwCw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: consulting@xxxxxxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Thu, 02 Nov 2023 14:24:31 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 02.11.2023 11:17, Federico Serafini wrote:
> On 30/10/23 16:01, Jan Beulich wrote:
>> On 25.10.2023 15:01, Federico Serafini wrote:
>>> Make function definition and declaration consistent and emphasize that
>>> the formal parameter is deliberately not used.
>>
>> Coming back to my earlier objection: Did you consider alternatives? Best
>> would of course be to get rid of the forward declaration. That seems
>> possible, albeit not quite as straightforward as it ended up being in
>> other cases. Second best would be to rename the parameter in the forward
>> declaration. Question of course in how far "emphasize that the formal
>> parameter is deliberately not used" is important here. (If it was, I
>> wonder why VT-d's do_iommu_page_fault() is left alone.)
>
> I can propose a new version of the patch with the second option.
> If one day you will decide to accept also Rule 2.7 ("A function
> should not contain unused parameters"), then a deviation based on
> the parameter name "unused" would be viable.
>
> If, however, there is interest in applying the first option,
> I think the best thing is for you to take care of it.
Done.
Jan
|
