On Mon, 23 Apr 2018, Lars Kurth wrote:
> Hi all,
>
> On 06/04/2018, 15:13, "Lars Kurth" <lars.ku...@citrix.com> 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
> pages):
> so, I don't think it is practical to work from the spec
>
> * Some coding style patterns will likely be perceived as odd and
> unreasonable
> 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.
Fantastic!
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
