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

Re: External file structure


  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Luca Fancellu <Luca.Fancellu@xxxxxxx>
  • Date: Tue, 24 Jan 2023 08:37:31 +0000
  • Accept-language: en-GB, en-US
  • 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=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=1FYTH3hGmJXQxOObp02/jdvKNKqvPJuOmnWAugX96Bc=; b=AqkxrkB+3Q3ExdXkq7d2q238G7SC9CWilg3F99n7t7U+eDp2wyerLhflvcTJw44KmZZ7TAmzv2etIxxnTC8SbgVOcm5Na8GPwzP7QvnVQ9VcpxinovpQYBOiPuAT4Baza3D7wlENWuyZTKuREGn0AoN8SH/QmsbR8n9dpARlGj6WBgSBuu4lVh1B/Iv7CNelFOORCG2yZTkQh6lg9b5lxcZQWz/6i+3s2f1YmmBmLewSuv74oPS/V7Gjfbib5JCZ6QKUuab1K8KfYz26CGv1R6i7RUE6zZkAhK2G3o3SzFPO13whK3yCOWuzgyZ0x8gNx3zNlOHm0IIWmWKGd1UxTQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fdeCQcl7Me+DzMszqa17ICsacZyWqplxxOVpYQgdwYFneM94lfO3tSTxu7WkemCdKefUCOJH+ybVAOQ8pGNmtujSZIrPxQoJomDlMzs6b46eHyLedeL0OC4xqHfk/FuRg0F5kMu7SQz3J9+2OKP+0c9haIELh6zOA8/yBg73cOh/R/iH/jjpway3eRxRcjICnXutaM/GoZ+DWcFe14sGhiOLc1KPmq8yaLDd42LiVlwl3oElTfmYmB/pkX6CIZzIgm8fHxtU3600xqzwFgh8mUZjglJT2Y/ehSYb30KZifUHXLHLMm0z6akMaqbp4QFHODPiyo2ru85DT9eJRdDahw==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Michal Orzel <michal.orzel@xxxxxxx>, "fusa-sig@xxxxxxxxxxxxxxxxxxxx" <fusa-sig@xxxxxxxxxxxxxxxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Delivery-date: Tue, 24 Jan 2023 08:38:06 +0000
  • List-id: This is a discussion list for members of the Xen Project FuSa SIG <fusa-sig.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: AQHZLxVx0YySRbM4tUebq/EW39PQca6r1diAgADLlQCAAJ6OgA==
  • Thread-topic: External file structure

Hi Michal, Stefano,

Thank you for your feedback,

>>> 
>>> docs/misra/external-files.json:
>>> {
>>>  "version": "1.0”,
>>>  "content": [
>>>    {
>>>      "path": "relative/path/from/xen/“,
>>>      "diverged": false,
>>>      "backport": "Y/N/?",
>> These two fields are more for the community/maintainers rather than for 
>> MISRA.
>> The reason is that we cannot deduct from that whether to exclude a file from 
>> MISRA/code checkers or not.
>> So we would need to have a separate field e.g. "exclude_from_checkers": 
>> "true/false".
>> This would also mean that we do not accept changes (normal changes, no 
>> backports) for such files,
>> e.g. to fix MISRA, coding style, etc.
> 
> It is true that we cannot deduct whether we should exclude a file from
> MISRA checkers from "diverged" and "backport", so here we need one more
> field like "exclude_from_checkers". A better name could be
> "exclude_from_misrac".
> 
> Once we have that, what do we do with "diverged" and "backport"? I think
> that we should just get rid of "diverged" because it is not very
> actionable info and not a "scientific" metric anyway.
> 
> That leaves us only with "backport". "backport" is useful and I think we
> should keep it.

I’m ok to remove diverged, because in the end what matters is if the file is 
still subject to backports
(so it is diverging from the xen code style at least in part), if it is not 
subject to backport it can be
simply “converted” to the xen code style and scanned with the tools.

Here I’m wondering instead if the backport flag is enough to remove the file 
form the scanned list,
because if backport is true then we cannot deviate from findings or fix 
false-positive, we could just
fix issues in the original project and backport them to Xen (and sometimes it’s 
not possible).
Instead if the field is false, then it should be “converted” to the xen 
codestyle and it can be subject of
fixes as any other file “owned” by Xen.

What are your thoughts?

Cheers,
Luca

 


Rackspace

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