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

Re: [Xen-devel] Xen and safety certification, Minutes of the meeting on Apr 4th (Notes on MISRA, ISO 26262 static code analysis requirements)

Hi all,

On 06/04/2018, 15:13, "Lars Kurth" <lars.kurth@xxxxxxxxxx> wrote:
    > 1) Requirements to the code, a subset of MISRA for ASIL B
    > Next step: get more information about requirements and publish it to
    > xen-devel.
    I see a few problems here:
    * The MISRA 2012 spec has to be bought and it is rather big (100's of 
    so, I don't think it is practical to work from the spec
    * Some coding style patterns will likely be perceived as odd and 
    by community members: as some common code would be affected we cannot 
    treat this in isolation say on ARM only. Although it is recognized that 
some of 
    the coding style patterns may not make sense, compliance to MISRA is 
    necessary and cannot normally be discussed away.
    * PRQA has set up an environment and initial MISRA compliance report for a 
Xen on ARM build 
    ** The question is what (if anything) can be shared publicly
    ** The other open question is whether we can come to some sort of longer 
term agreement between the Xen Project and PRQA to use their tools
    ** As an aside, what PRQA have done would need to reflect what we do in 
step 2 is. We also want to minimize the work for PRQA: in other words, it has 
to be very simple to enable the minimal config coming out of task 2 such that 
PRQA can 
    ** As far as I recall 90% of all MISRA violations come down to around 70 
issues. A large number are in tools
    ** Also, I believe that MISRA compliance tools will likely lead to a large 
amount of false positives, due to the distributed nature of Xen: process 
boundaries, kernel/user space boundaries, etc. would all lead to false 
positives, which somehow have to be managed.
    ACTION => Lars to follow up with Paul Luperto from PRQA
Hi all. I had a good meeting with Richard and Paul from PRQA today and it looks 
like we came up with a workable plan. There are a few things that will need 
checking, but this should be done in about 2 weeks. 

In essence there is a possibility for PRQA to make an instance of their 
QA·Verify Management Dashboard (see 
http://www.prqa.com/static-analysis-software/qa-verify/) to a small number (to 
be agreed) of community members initially on a suitable baseline for Xen on ARM 
(I would say Xen 4.11 or an RC would be a good starting point). I believe 
access should be restricted to committers, maybe people which committers 
delegate work to. After all, we want to enable an upsell route for PRQA, in 
return for providing a free service to the community. 

In any case, this would allow us to use the tool to follow the process I laid 
out above and get started.


Xen-devel mailing list



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