Thanks, Shuah, for pointing this out. The statement "A community member is maintaining and keeping this updated." may raise an interesting and relevant question from somebody's quality management/func

That sounds good. The malloc component already seems like a beast of known issues; let us see if that is a good starting point for a discussion or if there is something simpler? With my quick scan now

<sudip.mukherjee@...> wrote: Well, I think we can settle on looking at the upstream projects first. The distributions of interest can then be considered in a second round, among the contri

That sounds like a good strategy. We could call it a "pre-WG setting" to start with. For a change, let us start with looking at the known issues of a few open-source libc libraries, such as: - GNU C L

Sorry, I missed to answer this question in my previous email. The point above is the critical first task for a group to agree on. ISO 26262 mentions: "the reactions of the functions under anomalous op

That is correct. As the scope is limited to handling known issues, we can---even with a small team---probably cover more than just the kernel; further, the kernel development is certainly the most cha

Elana, so any system using Linux cannot be compliant to any safety standard that requires that for a system element based on Linux to present a list of known issues? If that is the case, we should wri

<Elana.Copperman@...> wrote: I agree with you, Elana. Solutions are required: - Tools to collect, track and evaluate known issues. Every automatic tool starts with a human understanding the p

Dear all, (Using the 'New working group proposal template' from https://github.com/elisa-tech/workgroups/blob/61d4beab67c3bc647086b1db41f0434ec2b98b31/new-wg-template.md) Proposed working group name K

<lukas.bulwahn=gmail.com@...> wrote: Jason, can you mark one artifact of the easy-marked ones as "highest priority and value to you" for us to trigger a new working (task) group? Thanks,

Just a quick assessment: "Easy"(TM, final last words...) --- let us try to present you something here. Difficult. What is a general risk? What is the system? Who needs to address? (I do not know what

<jason.smith=ul.com@...> wrote: Jason, could you elaborate on your expectation of the small additional pieces of information you see needed as quick wins? Can you put those pieces into a

I agree with these goals. However, I have noticed that in the last three years: - we could not produce a single _published_ result that contains the information from more than two authors (possibly,,

And a big thanks to Elana to start this; there is no need to look at the 18486 usages at first. It would be a good start to just look at the 1614 WARN_ON* in the kernel/ directory. Please either elimi

<Elana.Copperman@...> wrote: Good luck. Lukas

<Elana.Copperman@...> wrote: Sorry, Elana, this argument you are presenting above---with the autonomous car---is very pictorial, but hardly meets reality. What you are writing above suggests

Thanks, Shuah for pointing out the LWN article. Alex Popov pulled us into a kernel discussion this week on a specific kernel feature proposal with a remark that that is what safety-critical systems ne

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