Petr, that is basically the common system design taken. The whole challenge then remains to show that: Once panic() was invoked, the watched device does not signal being alive unintentionally, while t

<christophe.leroy@...> wrote: Christophe, I agree with a reasonable goal that WARN() should allow users "to deal with those situations as gracefull as possible, allowing the system to continue

Well, there is really a lot of thought and willingness for engineering effort to address the fact there must be high confidence that the shutdown with panic() really works. The proper start and restar

Alex, officially and formally, I cannot talk for the ELISA project (Enabling Linux In Safety Applications) by the Linux Foundation and I do not think there is anyone that can confidently do so on such

<lukas.bulwahn=gmail.com@...> wrote: I should also mention that I recommend asking developers working on memory management which verification activities and test suites they run and why t

<paul.albertella@...> wrote: Thanks, Paul, for those pointers. I can only recommend everyone to start understanding those investigations. I would like to point out another related investig

<gabriele.paoloni@...> wrote: I like your approach of visualizing the existing call-tree structure. That is nice and we did that, too, back in 2019 and 2020 and shared that with the group; just

<gabriele.paoloni@...> wrote: Well, from my experience, the only key criteria for a safety analysis is expert knowledge and expert judgement; all criteria on formality can be met independently o

<gabriele.paoloni@...> wrote: Thanks, Gab, so we need to show that any description of the software supports the safety analysis (risk assessment or risk mitigation) for a specific safety require

Oscar, thanks for this hint. So, the core criteria of any work for increasing confidence is: - to show that there an increase of understanding of the software and the system and the software's contrib

Dear all, I would propose an alternative approach to architecture: (1) There is a claim on a software, for which increased confidence in its validity is required. (2) There are aspects that provide ev

Dear all, I would propose a very simple "quick and easy" approach to architecture to comply with "safety standard X". (X may be replaced by any standard that meets assumption (1) below.) Assumptions:

Dear Qian ChunLei and Wang YuJue, I will not go into the details of the technical concerns you raised towards the proposed approach. I just quickly would like to confirm to you: I also feel sad and so

<Christopher.Temple@...> wrote: Yes, this is a good and interesting first step. I need to catch up on the actual application's safety goal, which faults were identified, the exact intended functio

Elana, why do you point to Eli, Gab and me in public? (As this public discussion thread shows there is no communication between Gab, Eli and me here at all; and I never responded to Gab's public answe

Gab, I request to immediately change the agenda because of a violation of the ELISA technical charter. Feel free to contact me if you have any questions. Thanks and best regards, Lukas

Gab, I think Thomas just confirmed my interpretation with his own words. Given the provided software (the current kernel source code), hardware (some x86 architecture chip) and hardware documentation

Okay, that is fine. But to say: "considering a random HW fault out of scope" is something very different to "We assume the HW to behave correctly." I can understand that "considering a random HW fault

<gabriele.paoloni@...> wrote: Well, I always said and keep saying: Anything actually technical valuable with regards to Linux kernel must end up in ./Documentation at https://git.kernel.org/pub/

Agree to 3. That is a very important point. Nevertheless, if panic would not work and we have no confidence on that operation, an important fault mitigation/mechanism would be missing in the overall s