RE: Xen FuSa meeting tomorrow Tue 17 November

[David Ward <david.ward@xxxxxxxxxxxxxxx>]

Hello Artem

ISO 26262 does refer to use of assembly, there is a note to Part 6 Clause 5.4.2 
(selection of programming languages) that says

"Assembly languages can be used for those parts of the software where the use 
of high‑level programming languages is not appropriate, such as low‑level 
software with interfaces to the hardware, interrupt handlers, or time‑critical 
algorithms. However using assembly languages can require a suitable application 
or tailoring of all software development phases (e.g. requirements of Clause 
8)."

So for clause 8 for example an appropriate coding guideline for assembler would 
be needed but it's unlikely there is a direct equivalent to MISRA C and we 
might have to do some digging for good practice we could adopt.

David

-----Original Message-----
From: Artem Mygaiev <Artem_Mygaiev@xxxxxxxx>
Sent: 01 December 2020 19:53
To: David Ward <david.ward@xxxxxxxxxxxxxxx>; fusa-sig@xxxxxxxxxxxxxxxxxxxx
Cc: stefanos@xxxxxxxxxx; Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>
Subject: RE: Xen FuSa meeting tomorrow Tue 17 November

Hello David

Thanks a lot for sharing! I am curious about current ISO26262 relation with 
MISRA but I need to learn more on the latest developments in MISRA (e.g. 
Compliance:2020) which, I must admit, I am not familiar with.

I have noticed that regulations like MISRA cover C / C++ but there is not much 
on assembly except its integration with high level languages. This is 
understandable because asm is too CPU-specific and not covered by some industry 
standards. In Xen we have plenty of Asm for some very low level CPU tasks, I am 
sure in some commercial systems situation is similar. What is the common 
approach on this?

Best regards,
 -- Artem

-----Original Message-----
From: Fusa-sig <fusa-sig-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of David Ward
Sent: Tuesday, 1 December, 2020 09:47
To: fusa-sig@xxxxxxxxxxxxxxxxxxxx
Cc: stefanos@xxxxxxxxxx; Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>
Subject: RE: Xen FuSa meeting tomorrow Tue 17 November

Hi all

With apologies for the delay here is a slightly edited copy of the slides I 
presented on MISRA Compliance. I probably won't be able to attend today's 
meeting as I have an ISO 26262 committee meeting that is likely to overrun.

Further questions, comments, etc. all welcome!


Best regards

David

-----Original Message-----
From: Fusa-sig <fusa-sig-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of Stefano 
Stabellini
Sent: 16 November 2020 22:49
To: Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>
Cc: fusa-sig@xxxxxxxxxxxxxxxxxxxx; stefanos@xxxxxxxxxx
Subject: Xen FuSa meeting tomorrow Tue 17 November

Hi all,

I would like to remind you that tomorrow it is time for our Xen FuSa SIG 
meeting. There are a number of outstanding actions, see below. Also, David Ward 
kindly volunteered to present on the subject of the MISRA Compliance 2020 
document, which is extremely relevant as it provides a framework to manage 
deviations.

Cheers,

Stefano



On Tue, 3 Nov 2020, Stefano Stabellini wrote:
> Hi all,
>
> These are the minutes of today's FuSa meeting.  Look for "ACTION" in
> the test to find the ACTION items.
>
> Cheers,
>
> Stefano
>
>
>
> # Build Xen with ARMClang
>
> Bertrand: ARM will internally build Xen with ARMClang to validate
> ARMClang against Xen. It is going to start in the next couple of months.
>
> Artem: I have opened a bunch of issues against ARMClang. What is the
> status?
>
> Bertrand: will check
>
> ACTION(Bertrand): ARM to let us know when issues are going to be fixed
> and in which version of the compiler.
>
> ACTION(Artem): send the ARMClang series for Xen again rebased on
> staging
>
>
> # Resiltech presentation on MISRAC
>
> First identify set of rules we have to comply to MISRAC. A subset of
> MISRAC, but which one?  Some rules are mandatory, some others are
> advisory?
>
> Who is responsible for deciding which rules are mandatory (R1)? It is
> important to have the safety experts involved.
>
> Once we identify the R1 rules, let's use static analysis to check for
> violations. For instance SonarCloud.
>
> We need to device who is responsible for fixing the violations, and
> what happens when developers say that the solution is worse than the
> original code.  There is a need for a final pass by a safety expert
> after the developer's analysis. In case the safety expert team
> identifies that the justification cannot be accepted the code has to be fixed.
>
>
> We need a tool able to process justifications for MISRAC violations
> inline with the code. It is important to maintain MISRAC violation
> justifications in sync with the code. Is there a tool that can do that
> today?
>
> If the tool doesn't support it, we could add scripting to it, so that
> we could extract the justifications from the comments and populate the
> tool's database ourselves.
>
>
> ACTION(Artem): work with Sonar and see how it handles justifications
> ACTION(Francesco): do an analysis on the tools and justification
> handling
>
>
> ACTION(Stefano): MISRAC justifiaction as incode comments, is it viable
>                  from a community perspective? Start the discussion.
> ACTION(Stefano): Diagram to describe the new contributor process
>                  workflow
>
>
> MISRAC document to provide a framework to manage deviations
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Feur01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fwww__%3BJSUl!!GF_29dbcQIUBPA!jv6qoVNZ0x2aLgPwmEAi2R_4YDx2XIkNll2hzJNknRLztHPisn88mGVXBCCPQJumbQ%24&amp;data=04%7C01%7Cdavid.ward%40horiba-mira.com%7Cae8e298163bf40f792c808d89632b6a5%7Caa85aed398b34cdab14015ccbb32c3b5%7C1%7C0%7C637424491841119064%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=BOAF7tdVNrMftaqz12r%2FqgS9uGxMIAAWNtXxxXJjoJQ%3D&amp;reserved=0
>  [eur01[.]safelinks[.]protection[.]outlook[.]com].
> misra.org.uk%2Fforum%2Fviewtopic.php%3Ff%3D241%26t%3D1842&amp;data=04%
> 7C01%7Cdavid.ward%40horiba-mira.com%7Ccb40aca41a72455a37c408d88a81e24b
> %7Caa85aed398b34cdab14015ccbb32c3b5%7C1%7C0%7C637411638461735298%7CUnk
> nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw
> iLCJXVCI6Mn0%3D%7C3000&amp;sdata=Zo8rXzN0OhsVKR1JT1L9cyZU6GUVmpzN4i4yM
> %2Fy6OZA%3D&amp;reserved=0 ACTION(David Ward): do a presentation on
> the topic during the next
>                     FuSa meeting.
>


HORIBA MIRA Ltd

Watling Street, Nuneaton, Warwickshire, CV10 0TU, England Registered in England 
and Wales No. 9626352 VAT Registration  GB 100 1464 84

This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you are not the named addressee you should not disseminate, distribute or copy 
this e-mail. Please notify the sender immediately by e-mail if you have 
received this e-mail by mistake and delete this e-mail from your system. If you 
are not the intended recipient you are notified that disclosing, copying, 
distributing or taking any action in reliance on the contents of this 
information is strictly prohibited.

HORIBA MIRA Ltd

Watling Street, Nuneaton, Warwickshire, CV10 0TU, England
Registered in England and Wales No. 9626352
VAT Registration  GB 100 1464 84

This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you are not the named addressee you should not disseminate, distribute or copy 
this e-mail. Please notify the sender immediately by e-mail if you have 
received this e-mail by mistake and delete this e-mail from your system. If you 
are not the intended recipient you are notified that disclosing, copying, 
distributing or taking any action in reliance on the contents of this 
information is strictly prohibited.