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

Proposal: List files in Xen originated from external sources


  • To: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Luca Fancellu <Luca.Fancellu@xxxxxxx>
  • Date: Fri, 3 Feb 2023 09:30:22 +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=q3UXGkM8sEuphNbb6hidIEP8SyILN4ARAxcRLlt4LEo=; b=OYWVsCG8vUgE2jksEchCnQajOh5HDakAaM5f451w9SaDqiJYT0KTapi/vmOWqFjfrgcFOeVOygUPBnaakLI5J8tg728AOb+qC8cleMXHyeDm3OQu5KTrIdKm3ARw3Kvk1KWipuNsPTF66p557G3lixL4b9gSUtOGw09ZpPX23Xoo8+9UG9sgT/fBWsT9m52Q5jKaSpRd62kQpyuikrePNf+pIZG0EGl2Zt2bdwBUr0RUK3+pXuZ06eC3FvJSFHL5JrYaYo9DMQkZv98rm752CqAkDIhoMrtrXd4AtuLDgDVW8bB9lcYLuwFE7DN308GYCpSZRu17tZ3FqycvvL+ySA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J8apfnEPmlIpAwqqoSI4MQIb/wfP3oosxM+exw2EwfG9CvVzOiemGlrmaD8aody19yxWxtfZakfCziAtoDxrCea6TvGRwt8/EGbRz5Xhz+KO+001IlKHqhsbgJhQrDDwGSrwFK02mVVNebisPHWbvtHs46ZSrx56gQFoSSJKT8+J3c7zVaKjLHAHPW1qlN4skwWGUvzJIgZ3TNYSSXtX69Qj4R7ReJ1FUCpTh+qXsuHC2UeSqOchtuvZyjrLzsbKz1qQ7eQ/c01/VzzuD/Mgt5jWOPdWYF7vXlWK578xZv4YIKavlAxiD9btBiTLkk0w+VnixAcUyL3NApM0NrN/8g==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>
  • Delivery-date: Fri, 03 Feb 2023 09:30:50 +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: AQHZN7IjdE2jT11hbUWRAoU6FDszqA==
  • Thread-topic: Proposal: List files in Xen originated from external sources

Hi all,

I’m starting a proposal for the external files that needs to be removed from 
the MISRA scan,
the work was originally started by Michal here:
https://patchwork.kernel.org/project/xen-devel/patch/20221116092032.4423-1-michal.orzel@xxxxxxx/
so I started by that thread, the aim of this work is to have an initial format 
to start as soon as possible to
exclude the external files from the MISRA scan (at least initially from 
cppcheck).

I think we can use the JSON format because it’s easy to integrate it with 
python and it’s easy to add/remove
fields from the structure without interfering with the other elements during 
time, so we can define a structure
now but if in the future we see the needs for additional field, we can just add 
them without changes to the
analysis script.

In my opinion many of these fields can be left empty in a first push, to let 
the script exclude the files and during
time with the contributions of the community we can add the missing 
informations.
I think it’s easier for the community to pick an entry, do some research to 
fill the gaps and push, instead to wait
until having all the informations before adding the entry.


This is my first though for the fields, let me know yours:

docs/misra/external-files.json:
{
 "version": "1.0”,
 "content": [
   {
     "path": "relative/path/from/xen/“,
     "backport": True/False,
     "origin_project": "URL to origin project",
     "origin_path": "relative path in the original project",
     "origin_revision": "revision in original project”
   }
 ]
}


Maybe, documentation for this file and the fields can reside in 
docs/misra/external-files.rst.

Here follows the explanation for the fields:

path: is a relative path from the xen base folder, it can refer to a file or it 
can be a path to an entire folder
         (Taking as example libfdt)

backport: it’s a boolean flag that says if the file is subject to backport, so 
every file where this field is true
                won’t be included in the analysis. A file is subject to 
backport when it’s external and it doesn’t
                accept direct changes (changes needs to be made in the original 
project and then backported
                to Xen)

origin_project: url of the repository where this file was originated

origin_path: relative path in the original project, mostly linked to the 
original_revision field

origin_revision: revision of the changes in the repository when this file was 
taken.


Now, I’m not entirely sure about the field “backport”, because if a file is not 
subject to backport, then why
we should not make direct changes? Shall we maybe change its codestyle and 
convert it to Xen codestyle?
And then, if the file is not subject to backport and now we “own” the file, 
there is no more the need to list it
in the external file, a commit search can reveal when it was converted to Xen 
codestyle and removed from
the external file list so we don’t lose the history.
So we would end up excluding just all the file listed in external-file.json by 
the analysis.

What are your thoughts about that? Thank you


Cheers,
Luca

 


Rackspace

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