On Wed, Sep 29, 2021 at 10:58 AM Elana Copperman
<Elana.Copperman@...> wrote:

We can start with cgroups and namespaces, focusing on the questions raised by Bruce and Priyanka in their presentation last week.
Emails would work if you would leave the original full discussion, it is very difficult to follow this censored flow.

Agree. That is a really good idea. We need to establish proper
recommendations and policies for well-structured email-based
discussions. I will reach out to Shuah for the TSC meeting today to
have a smaller group describe recommendations and policies for
well-structured email-based discussions.

Then, we document those for the overall group exchanging emails, and
potentially even enforce certain policies for email discussions, such
as already done on linux-kernel@..., and continuously
pointed out by some technical stewards/mentors on similar lists.

Lukas

-----Original Message-----
From: Lukas Bulwahn <lukas.bulwahn@...>
Sent: Wednesday, September 29, 2021 11:51 AM
To: Elana Copperman <Elana.Copperman@...>
Cc: Paul Albertella <paul.albertella@...>; devel@...
Subject: Re: [ELISA Technical Community] New WG proposals: Safety Engineering Process, Linux Developers

On Wed, Sep 29, 2021 at 8:38 AM Elana Copperman <Elana.Copperman@...> wrote:

Lukas, this discussion does not seem to be appropriate for the mailing list, and if there is sufficient interest - we can use tomorrow's call for this purpose. @Paul Albertella?

In brief, the process which you describe below gets stuck because Linux is not qualified. To accept a kernel patch as a basis for safety claims, given that such a patch inevitably uses existing kernel features, our experience has been that you would need a fully qualified Linux kernel to support the kernel patch development process.

Okay, thanks. Now, I understand why we get stuck. Of course, if we come to the conclusion that a fully qualified Linux kernel (whatever that means; I have no clear semantics for such a term; qualification always happens in the context of a (assumed) system) is required for any feature we may develop, then we really might be stuck.

I resolved that question for the scope that was required for the feature to be integrated. By employing general software engineering arguments, I could limit that to a clearly manageable scope of kernel functionality. If there is interest in how that is resolved, I would suggest just looking at a specific feature and reconsider the challenge we encountered that leads to the point above.

I am not a big fan of meetings; email is often the better means of communication for technical discussions. Only, seldomly, a meeting really adds value to a discussion of in-depth considerations.

Lukas