|
[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
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.
Regards
Lars
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |