Re: New WG proposals: Safety Engineering Process, Linux Developers


elana.copperman@...
 

Thanks, Lukas, for your comments.  See brief replies below; we should continue this discussion next week, on my return from holiday.


From: Lukas Bulwahn <lukas.bulwahn@...>
Sent: Monday, September 20, 2021 10:00 PM
To: Elana Copperman <Elana.Copperman@...>
Cc: devel@... <devel@...>; Paul Albertella <paul.albertella@...>
Subject: Re: [ELISA Technical Community] New WG proposals: Safety Engineering Process, Linux Developers
 
> I agree with your assessment of the key challenge.
> In that regard, providing a supportive environment, I think one of the
> first points might be to understand:
>
> - What is currently blocking those who actually design and develop
> production systems to contribute the features? knowledge gap?
> organisational aspects? some missing alignment?
> [EC} Blocking by safety assessment.  It is straightforward to qualify proprietary (not open-source) safety mechanisms in user applications.  Kernel patches, however, are currently impossible to qualify.  This is a major issue which I hope Paul can address.
>

My question was really looking for more practical answers here.
E.g., just for the purpose of illustration: Although I understand what
kind of changes to the memory management system might help verifying
or validating critical property (relevant for safety systems), I
cannot implement and submit anything relevant to the kernel's memory
management because I personally do not have the necessary in-depth
knowledge for memory management.

Your hypothesis "Kernel patches are currently impossible to qualify"
needs to be due to certain reasons; I would really like to understand
why this is currently impossible? Is it due to lack of knowledge about
the contributor and its development process? Is it due to lack of
expertise in understanding and judging the existing code? etc.
>>>>  Not at all.  It is the basic mistrust of Linux which is manifested in ELISA as well. 
>>>>  We are seeing in the Architecture WG what a long process would be needed for a trivial use case.
>>>>  Qualifying a complex real-life production use case for release as a kernel patch would incur unreasonable cost, effort and resources.

> - What does the forum on the linux-kernel mailing list and related
> development channel already offer to provide a supportive environment
> for those who actually design and develop production systems?
> [EC] Nothing.  Hopefully the new WG with Paul's leadership will make some breakthroughs.
>

Again, I would like to understand this more specifically:

Stating that the linux-kernel mailing list provides nothing, seems a
bit harsh. 
>>>> Where was this statement made?  

For the code improvement group, we identified that the
linux-kernel mailing list provides a way for obtaining feedback and
integrating our improvements (and that we do not need any separate
channels, communities or networks); we just lack partly the
skill/comprehension and partly the time to assess all bug
findings/issues we identified, but for a few simple issues, each
participant could submit an improvement and get it integrated with the
help of the linux-kernel mailing list and the established maintainers.

Can you not integrate the features you developed through the
linux-kernel mailing list? Is that broken for the code you would like
to modify and extend? Why are these features rejected?
>>>> ??? Who developed features through the Linux kernel mailing list?

> - What is missing in the linux-kernel community to provide a
> supportive environment for those who actually design and develop
> production systems?
> [EC] A forum for collaboration with safety experts.  Collaboration means listening to each other and working together.  Not an easy challenge.
>
> - How can we address those missing aspects to provide a supportive
> environment for those who actually design and develop production
> systems?
> [EC] that's what Paul and I are trying to do.  🙂
>
> I currently have only a rough understanding of the blockers from
> informal discussions among developers and some managers, but I think
> the topics that are blocking contributions are widely spread, and
> partly deeply rooted, such as technical knowledge gap or challenging
> strategic considerations, such as developing a proper open-source
> strategy that includes investments in upstream work.
>
> I would be interested to see if we could create a---potentially
> anonymized (under Chatham House Rules))---list of blockers for those
> who actually design and develop production systems to effectively
> contribute.
> [EC] You are welcome to get this started.
>

Let us see if there are others that are willing to share their experiences.


Lukas

Join devel@lists.elisa.tech to automatically receive all group messages.