[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/2] docs/misra: add Rule 5.1


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Date: Thu, 26 May 2022 10:10:05 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=2; 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=i8UITn91FnvY8HhDxe5rHXOeAambHx3RHnejjSQpW1c=; b=J91DtUON7yvcZyrxhtRgGQsUAmZkgLvCOtravpvOjeBiWZr7m2TrtOAMS/8g9A1rx4DZ9lTcKlwhscz5/D0OWZZzL5yKGgELlcZqRJzV7ip5nhfJ4vCZrkfKmInAWi2B3pEUmY85lOXn8vtWtXFnyRq+jAj+MoGpB1opOD7BndsTDjivaB4jgGComurKz7M9oTPDRx9FU4cd1gXIoB9NvNybvVsOO9/DyqwguzYWM5g25XzXlqF3ufuuz2EX7w0mu9xVc2C0w2OOUwHIeI+kK42rJiKg8S8GbzVSKu0kqWkKu1hizaJpihQyOoiTzDRCVca90yXkNcz89f6KHlCzWw==
  • 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=i8UITn91FnvY8HhDxe5rHXOeAambHx3RHnejjSQpW1c=; b=Lvej6QQ46X1tlF+YYeOknQsUuYP7ITV3JAKlGPbWwdfV+NlbQ83aH76wI6OtPMbUHI4f7u72WHnaajlXxnv+34UbsACCrAB6nVPbdzdNAjEb3IpJ4cgFLoY9OsSjBSn34SBNLwt5Z/zC/gQmsJ7iNe5QsHidAiqnDY96QRxPVFXaaAJoPnnZ3hRbprf6cxeZ350pDjlVn9n2FK0LyVlwZmn0wUW5+xRZRsYM63p9KywdPMZypjLIoz/lw8Pf3aEsgQmN+BJDOAMdJEywXBazTu4ZO6OEMxryPXruRQrNHC85SycBUr1Ke3Yx8DmxcqGIcL02dy8x7vNJu9bisCS1dQ==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=d5W7e+DjeOq7gz3sM7b6MDSuIgzFZz6pwBPT675x7t/Npbf7ohZH3qE0TbFEuENudThCxXV5nL7CynDs+CfFwc4Cu4yWavwDzBVrgveHJhFKcknlMnvNOv4aTsoy8akRoDs6BFGXGtNLeAZXXWu3FwVfablgcgXDgl7UtXEMlZjZY++PJR9uJlhIWqZEKkhFG2N0mc9z8DAhuDEK9O6pzZBgJhoBsbqF5IdzDKBCoyzds0Zcn6xN/e6yF1ioHSNMGGgcgzajauhSMRjUNiVxSI+ktMd3clyOSFRBtc/x03vbVhVmBCLKYDNSVI2PTdkIYx2hNx03ks32KkD0GizDVA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V6msmo87+pPxbdmNhTbhLqxvqFEnzIAwGfniQ0/f9N6sd30su9eKzH+mWCipjtyIVyAEx41nl879aNtCvsWicRvi15mBwLbfUdIcVF9GTsGPSbeLtIh5lDTn6GBKMBcFe29l5Fc00xdoqUQVCSpOy2OrsuIbu2exXQwT8zAyA8rEmaSheBWJOXEUNVDzCJh0jva/VMi/J70y5pat93qdeOxebUofnJfT+HBptlOLi8ysP71UYFbH4Q5ty9Fh1KWSUOHRRqbd8Bk0bXYd1pSbx0kU77QVVf0GnRT33ZIU4Zt4Sg+jn7PCFi9hU/OVzsuf5H3Ooz4syQkRDZiOeDybPA==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, "andrew.cooper3@xxxxxxxxxx" <andrew.cooper3@xxxxxxxxxx>, "roger.pau@xxxxxxxxxx" <roger.pau@xxxxxxxxxx>, "julien@xxxxxxx" <julien@xxxxxxx>, "George.Dunlap@xxxxxxxxxx" <George.Dunlap@xxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 26 May 2022 10:10:25 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHYb89RqYcZa7uXSUe8aa9iaX1mVK0vPZ+AgAEfowCAAIxHgIAACGKA
  • Thread-topic: [PATCH 2/2] docs/misra: add Rule 5.1


> On 26 May 2022, at 10:40, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
> On 26.05.2022 03:18, Stefano Stabellini wrote:
>> On Wed, 25 May 2022, Jan Beulich wrote:
>>> On 25.05.2022 02:35, Stefano Stabellini wrote:
>>>> From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>
>>>> 
>>>> Add Rule 5.1, with the additional note that the character limit for Xen
>>>> is 63 characters.
>>>> 
>>>> The max length identifiers found by ECLAIR are:
>>>> 
>>>> __mitigate_spectre_bhb_clear_insn_start
>>>> domain_pause_by_systemcontroller_nosync
>>>> 
>>>> Both of them are 40 characters long. A limit of 63 characters work for
>>>> the existing code.
>>> 
>>> I have to admit that it hasn't become clear to me why we want to
>>> permit (if not to say encourage) the use of such long identifiers.
>>> If 40 is the longest we've got, why not limit it to 40 for now
>>> with a goal of further reducing? A 40-char symbol plus some
>>> indentation will already pose problems with 80-char line length.
>> 
>> We can go lower than 63 if we want to. I chose the closest power-of-two
>> length -1 for the NUL terminator. But it doesn't have to be a
>> power-of-two. So we could go with "41" if we want to.
>> 
>> Anyone in favor of that? I am happy with any number between 41 and 63.
> 
> Why 41, not 40? 41 seems yet more arbitrary to me than e.g. 40.
> 
>>> Otoh, as said on the call, I think the public headers want
>>> mentioning explicitly here in some way. Part of them (most or all
>>> of what's under io/) aren't used when building Xen, so won't be
>>> seen by Eclair (aiui). Yet they are a formal part of the code
>>> base, and e.g. ring.h has some pretty long names (albeit still
>>> below 40 chars as it looks). So once we're able to go down to e.g.
>>> 32 for the bulk of the code base, public headers should imo still
>>> be explicitly allowed to use longer identifiers.
>> 
>> Actually I thought about writing something for the public header but I
>> wasn't sure what to write. What about:
>> 
>> - Note: the Xen characters limit for identifiers is 41. Public headers
>> (xen/include/public/) are allowed to retain longer identifiers for
>> backward compatibility.
> 
> Fine with me, except I wonder in how far going forward we actually
> need to play by that limit there. Proper name-spacing is particularly
> important in the public headers, so may warrant a higher limit for
> certain (unusual?) circumstances.

I think we can have a “global” deviation for public headers with an higher
limit but there should still be a limit.

Bertrand

> 
> Jan


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.