[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)
On Mon, 23 Apr 2018, Lars Kurth wrote: > 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. Fantastic! _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |