TSC Meeting Agenda - February 16 2022


elana.copperman@...
 

Thanks, Wenhui; I think you replied on the wrong email.

Anyhow, I will branch back to LFSCS and post the proposed agenda.

Regards

Elana

 

From: Wenhui Zhang <wenhuizhang.psu@...>
Sent: Monday, February 21, 2022 7:39 PM
To: Elana Copperman <Elana.Copperman@...>; ruide.zhang.r@...
Cc: Smith, Jason <Jason.Smith@...>; Lukas Bulwahn <lukas.bulwahn@...>; Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

Hi, 

 

Ruide( ruide.zhang.r@... ) from security team and me from IaaS of bytedance/TikTok will be explaining our need for more documentation and tutorials on safety configurations for VM/Host in cloud.

 

Wenhui 

 

On Wed, Feb 16, 2022, 8:22 AM <elana.copperman@...> wrote:

Hi all,

A point to consider when choosing tasks:  perhaps we should define clear criteria, based on potential benefit to the community - and include that message in the introduction or overview.  Then try to focus on those tasks with highest potential benefit.

I am finding it difficult even to understand the intent or purpose of some of these documents.

Elana

 


From: Smith, Jason <Jason.Smith@...>
Sent: Wednesday, February 16, 2022 6:17 PM
To: Lukas Bulwahn <lukas.bulwahn@...>
Cc: Elana Copperman <Elana.Copperman@...>; Shuah Khan <skhan@...>; devel@... <devel@...>
Subject: RE: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

Hi Lukas,

Thanks for your reply.

I missed the very end of today's meeting (apologies to all for having to drop off the call before it concluded) so I'm not sure if and how much this was discussed further, but even some of the items you identified below that are "difficult" may not be so much if the efforts are constrained to a specific feature of Linux or are meta/high-level in nature.

Specific to your most recent message, the one item that I think would be useful to those who are just looking to create a safer system using Linux, or are looking to use Linux in the context of a system that requires conformance with a safety standard that allows treating Software of Unknown Pedigree (SOUP) as-is, would be release notes that document what are the known issues with Linux - whether they be of the nature of "don't do this; it's not a bug/defect, but if you implement something this way, you will get bad results" or actual, genuine software defects or bugs.

Unfortunately, I'm going to be off work during the next workshop in April and will not be able to present on any topics, so it'll be important for me to keep talking about these topics during our weekly meetings to keep momentum going.

Jason


-----Original Message-----
From: Lukas Bulwahn <lukas.bulwahn@...>
Sent: Wednesday, February 16, 2022 10:05 AM
To: Lukas Bulwahn <lukas.bulwahn@...>
Cc: Smith, Jason <Jason.Smith@...>; elana.copperman@...; Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

On Wed, Feb 16, 2022 at 3:13 PM Lukas Bulwahn via lists.elisa.tech <lukas.bulwahn=gmail.com@...> wrote:
>
> On Wed, Feb 16, 2022 at 2:49 PM Smith, Jason <Jason.Smith@...> wrote:
> >
> > A quick reply to Lukas prior to our meeting (I apologize, didn't have time to prioritize):
> >
> > We should revisit the work I/we started to do two years ago that never really materialized into anything, which is partially if not completely my own fault; conclusions from the third draft of the white paper I was working on:
> >
>
> Just a quick assessment:
>
> > - Manual, including general information pertaining to the Linux distribution like the version/revision and descriptions of APIs, etc.
>
> "Easy"(TM, final last words...) --- let us try to present you something here.
>
> > - Fault Analysis, identifying general risks associated with the use
> > of Linux and how those risks have been (or should be) addressed
>
> Difficult. What is a general risk? What is the system? Who needs to
> address? (I do not know what to do...) --- let us postpone.
>
> > - Design Guide, providing recommendations for appropriate hardware
> > and software architectures to use for safety applications
>
> Difficult. Again, needs an assumption on a system --- let us postpone.
>
> > - Verification and Validation Report, describing the procedures,
> > methods, and criteria used to develop and test that Linux
> > distribution prior to its release, and the results of those tests
>
> "Easy"(TM, final last words...) --- let us try to present you something here.
>
> > - Release Notes, describing any known issues or bugs in that
> > particular Linux distribution
>
> "Easy"(TM, final last words...) --- let us try to present you something here.
>
> Would you see some priority on the easy-marked ones and would you
> accept to postpone the two difficult ones?
>

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,

Lukas

> Then, I could present some "examples" for the easy results, and see
> where we go from there.
>
> Lukas
>
>
> >
> > Jason
> >
> > -----Original Message-----
> > From: Lukas Bulwahn <lukas.bulwahn@...>
> > Sent: Wednesday, February 16, 2022 7:38 AM
> > To: Smith, Jason <Jason.Smith@...>
> > Cc: elana.copperman@...; Shuah Khan
> > <skhan@...>; devel@...
> > Subject: Re: [ELISA Technical Community] TSC Meeting Agenda -
> > February 16 2022
> >
> > On Thu, Feb 10, 2022 at 4:29 AM Smith, Jason via lists.elisa.tech <jason.smith=ul.com@...> wrote:
> > >
> > > My goals are quick wins.  There are safety applications using Linux that either don't need safety certification or whose standards allow Linux to be treated as-is, i.e. software of unknown pedigree.  Just small improvements to Linux or relatively small additional pieces of information provided with Linux could offer a lot of value to these developers, allowing them to build safer products.  Examples: code improvements, new modules that add or support software safety measures, white papers, manuals, design guides, fault analyses, reports (verification, validation, review, etc.), release notes including known issues, etc.  In a way, this is perhaps a scaled-down version of Elana's (3).
> > >
> >
> > 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 prioritized list?
> >
> > Then, we could start at the top of that list and present an example of such pieces of information and discuss them with you to determine the potential effort of providing such information regularly (e.g., for every version) and completely (not just as some incomplete example for the purpose of having a discussion).
> >
> > I would like to contribute to creating that you see as quick wins. For me, there is nothing to lose here.
> >
> >
> > Lukas
> >
> > >
> > >
> > > That being said... I don't know if this is exactly what the community needs.
> > >
> > >
> > >
> > > I think (if we haven't done so already) we should go out far and wide across not only ELISA but Linux developers in general to find out what they really need.
> > >
> > >
> > >
> > > Are there enough developers of safety applications using Linux that are okay with treating Linux as-is, making it worthwhile to pursue my stated goal?
> > >
> > >
> > >
> > > Or are most folks trying to develop systems for self-driving cars using Linux and ultimately need compliance with ISO 26262?
> > >
> > >
> > >
> > > If the latter is true, start with Elana's (1).  It's going to be a lot of work.
> > >
> > >
> > >
> > > Jason
> > >
> > >
> > >
> > > From: devel@... <devel@...> On Behalf Of
> > > elana.copperman via lists.elisa.tech
> > > Sent: Wednesday, February 09, 2022 9:37 AM
> > > To: Shuah Khan <skhan@...>; devel@...
> > > Subject: Re: [ELISA Technical Community] TSC Meeting Agenda -
> > > February
> > > 16 2022
> > >
> > >
> > >
> > > Thanks, Shuah.  Some goals/ideas from my side:
> > >
> > > To establish a framework for communication and collaboration between Linux kernel developers/maintainers, safety experts and designers/developers of Linux based safety critical systems.  Without broader representation and communication, the work products of ELISA cannot have a context for deployment and acceptance.
> > > ELISA is a project of the Linux Foundation.  To leverage this umbrella, learn from its strong points, and help to improve the weaker points towards the long-term goal of integrating Linux successfully in safety critical systems.
> > > Work products (actual kernel patches) which will support the original ELISA mission statement:   to define and maintain a common set of elements, processes and tools that can be incorporated into Linux-based, safety-critical systems amenable to safety certification.
> > >
> > > Regards
> > >
> > > Elana
> > >
> > > ________________________________
> > >
> > > From: devel@... <devel@...> on behalf of
> > > Shuah Khan <skhan@...>
> > > Sent: Wednesday, February 9, 2022 5:20 PM
> > > To: devel@... <devel@...>
> > > Cc: Shuah Khan <skhan@...>
> > > Subject: [ELISA Technical Community] TSC Meeting Agenda - February
> > > 16
> > > 2022
> > >
> > >
> > >
> > > EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.
> > >
> > > All,
> > >
> > > Let's meet next week to discuss alignment on goals and what
> > > success looks like. Please respond to this thread to add you 1 or
> > > 2 items you consider important to achieve ELISA goals and make the
> > > project successful.
> > >
> > > I will compile the items and share the consolidated list before
> > > the meeting.
> > >
> > > thanks,
> > > -- Shuah
> > >
> > >
> > >
> > >
> > >
> > >
> > > This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
> > >
> > >
> >
> > This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
>
>
>
>
>

This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.


Wenhui Zhang
 

Hi, 

Ruide( ruide.zhang.r@... ) from security team and me from IaaS of bytedance/TikTok will be explaining our need for more documentation and tutorials on safety configurations for VM/Host in cloud.

Wenhui 

On Wed, Feb 16, 2022, 8:22 AM <elana.copperman@...> wrote:
Hi all,
A point to consider when choosing tasks:  perhaps we should define clear criteria, based on potential benefit to the community - and include that message in the introduction or overview.  Then try to focus on those tasks with highest potential benefit.
I am finding it difficult even to understand the intent or purpose of some of these documents.
Elana


From: Smith, Jason <Jason.Smith@...>
Sent: Wednesday, February 16, 2022 6:17 PM
To: Lukas Bulwahn <lukas.bulwahn@...>
Cc: Elana Copperman <Elana.Copperman@...>; Shuah Khan <skhan@...>; devel@... <devel@...>
Subject: RE: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022
 
EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

Hi Lukas,

Thanks for your reply.

I missed the very end of today's meeting (apologies to all for having to drop off the call before it concluded) so I'm not sure if and how much this was discussed further, but even some of the items you identified below that are "difficult" may not be so much if the efforts are constrained to a specific feature of Linux or are meta/high-level in nature.

Specific to your most recent message, the one item that I think would be useful to those who are just looking to create a safer system using Linux, or are looking to use Linux in the context of a system that requires conformance with a safety standard that allows treating Software of Unknown Pedigree (SOUP) as-is, would be release notes that document what are the known issues with Linux - whether they be of the nature of "don't do this; it's not a bug/defect, but if you implement something this way, you will get bad results" or actual, genuine software defects or bugs.

Unfortunately, I'm going to be off work during the next workshop in April and will not be able to present on any topics, so it'll be important for me to keep talking about these topics during our weekly meetings to keep momentum going.

Jason


-----Original Message-----
From: Lukas Bulwahn <lukas.bulwahn@...>
Sent: Wednesday, February 16, 2022 10:05 AM
To: Lukas Bulwahn <lukas.bulwahn@...>
Cc: Smith, Jason <Jason.Smith@...>; elana.copperman@...; Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

On Wed, Feb 16, 2022 at 3:13 PM Lukas Bulwahn via lists.elisa.tech <lukas.bulwahn=gmail.com@...> wrote:
>
> On Wed, Feb 16, 2022 at 2:49 PM Smith, Jason <Jason.Smith@...> wrote:
> >
> > A quick reply to Lukas prior to our meeting (I apologize, didn't have time to prioritize):
> >
> > We should revisit the work I/we started to do two years ago that never really materialized into anything, which is partially if not completely my own fault; conclusions from the third draft of the white paper I was working on:
> >
>
> Just a quick assessment:
>
> > - Manual, including general information pertaining to the Linux distribution like the version/revision and descriptions of APIs, etc.
>
> "Easy"(TM, final last words...) --- let us try to present you something here.
>
> > - Fault Analysis, identifying general risks associated with the use
> > of Linux and how those risks have been (or should be) addressed
>
> Difficult. What is a general risk? What is the system? Who needs to
> address? (I do not know what to do...) --- let us postpone.
>
> > - Design Guide, providing recommendations for appropriate hardware
> > and software architectures to use for safety applications
>
> Difficult. Again, needs an assumption on a system --- let us postpone.
>
> > - Verification and Validation Report, describing the procedures,
> > methods, and criteria used to develop and test that Linux
> > distribution prior to its release, and the results of those tests
>
> "Easy"(TM, final last words...) --- let us try to present you something here.
>
> > - Release Notes, describing any known issues or bugs in that
> > particular Linux distribution
>
> "Easy"(TM, final last words...) --- let us try to present you something here.
>
> Would you see some priority on the easy-marked ones and would you
> accept to postpone the two difficult ones?
>

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,

Lukas

> Then, I could present some "examples" for the easy results, and see
> where we go from there.
>
> Lukas
>
>
> >
> > Jason
> >
> > -----Original Message-----
> > From: Lukas Bulwahn <lukas.bulwahn@...>
> > Sent: Wednesday, February 16, 2022 7:38 AM
> > To: Smith, Jason <Jason.Smith@...>
> > Cc: elana.copperman@...; Shuah Khan
> > <skhan@...>; devel@...
> > Subject: Re: [ELISA Technical Community] TSC Meeting Agenda -
> > February 16 2022
> >
> > On Thu, Feb 10, 2022 at 4:29 AM Smith, Jason via lists.elisa.tech <jason.smith=ul.com@...> wrote:
> > >
> > > My goals are quick wins.  There are safety applications using Linux that either don't need safety certification or whose standards allow Linux to be treated as-is, i.e. software of unknown pedigree.  Just small improvements to Linux or relatively small additional pieces of information provided with Linux could offer a lot of value to these developers, allowing them to build safer products.  Examples: code improvements, new modules that add or support software safety measures, white papers, manuals, design guides, fault analyses, reports (verification, validation, review, etc.), release notes including known issues, etc.  In a way, this is perhaps a scaled-down version of Elana's (3).
> > >
> >
> > 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 prioritized list?
> >
> > Then, we could start at the top of that list and present an example of such pieces of information and discuss them with you to determine the potential effort of providing such information regularly (e.g., for every version) and completely (not just as some incomplete example for the purpose of having a discussion).
> >
> > I would like to contribute to creating that you see as quick wins. For me, there is nothing to lose here.
> >
> >
> > Lukas
> >
> > >
> > >
> > > That being said... I don't know if this is exactly what the community needs.
> > >
> > >
> > >
> > > I think (if we haven't done so already) we should go out far and wide across not only ELISA but Linux developers in general to find out what they really need.
> > >
> > >
> > >
> > > Are there enough developers of safety applications using Linux that are okay with treating Linux as-is, making it worthwhile to pursue my stated goal?
> > >
> > >
> > >
> > > Or are most folks trying to develop systems for self-driving cars using Linux and ultimately need compliance with ISO 26262?
> > >
> > >
> > >
> > > If the latter is true, start with Elana's (1).  It's going to be a lot of work.
> > >
> > >
> > >
> > > Jason
> > >
> > >
> > >
> > > From: devel@... <devel@...> On Behalf Of
> > > elana.copperman via lists.elisa.tech
> > > Sent: Wednesday, February 09, 2022 9:37 AM
> > > To: Shuah Khan <skhan@...>; devel@...
> > > Subject: Re: [ELISA Technical Community] TSC Meeting Agenda -
> > > February
> > > 16 2022
> > >
> > >
> > >
> > > Thanks, Shuah.  Some goals/ideas from my side:
> > >
> > > To establish a framework for communication and collaboration between Linux kernel developers/maintainers, safety experts and designers/developers of Linux based safety critical systems.  Without broader representation and communication, the work products of ELISA cannot have a context for deployment and acceptance.
> > > ELISA is a project of the Linux Foundation.  To leverage this umbrella, learn from its strong points, and help to improve the weaker points towards the long-term goal of integrating Linux successfully in safety critical systems.
> > > Work products (actual kernel patches) which will support the original ELISA mission statement:   to define and maintain a common set of elements, processes and tools that can be incorporated into Linux-based, safety-critical systems amenable to safety certification.
> > >
> > > Regards
> > >
> > > Elana
> > >
> > > ________________________________
> > >
> > > From: devel@... <devel@...> on behalf of
> > > Shuah Khan <skhan@...>
> > > Sent: Wednesday, February 9, 2022 5:20 PM
> > > To: devel@... <devel@...>
> > > Cc: Shuah Khan <skhan@...>
> > > Subject: [ELISA Technical Community] TSC Meeting Agenda - February
> > > 16
> > > 2022
> > >
> > >
> > >
> > > EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.
> > >
> > > All,
> > >
> > > Let's meet next week to discuss alignment on goals and what
> > > success looks like. Please respond to this thread to add you 1 or
> > > 2 items you consider important to achieve ELISA goals and make the
> > > project successful.
> > >
> > > I will compile the items and share the consolidated list before
> > > the meeting.
> > >
> > > thanks,
> > > -- Shuah
> > >
> > >
> > >
> > >
> > >
> > >
> > > This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
> > >
> > >
> >
> > This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
>
>
>
>
>

This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.


Wenhui Zhang
 

Hi, Elena:
I could help with the explanation then.

Wenhui 

On Mon, Feb 21, 2022, 12:46 AM Elana Copperman <Elana.Copperman@...> wrote:

Thanks, Wenhui.

Would it be possible for someone who speaks English reasonably well to join the meeting tomorrow, and to clarify for the group what specific requirements could be focused?  This would be an interesting way to get practical feedback to guide our work.

Regards

Elana

 

From: Wenhui Zhang <wenhuizhang.psu@...>
Sent: Sunday, February 20, 2022 6:36 PM
To: Elana Copperman <Elana.Copperman@...>
Cc: Smith, Jason <Jason.Smith@...>; Lukas Bulwahn <lukas.bulwahn@...>; Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

Hi, Elana

 

We discussed with China Team of TikTok for what we would like to learn.

 

Linux safety Configurations' usage , guarantees and performance tradeoffs. 

 

The recommendation for Linux safety configurations  both guest os in private cloud, guest os in public cloud, Host os in private cloud and host os in public cloud. 

 

 

The recommendation for Linux safety configurations for OLAP cluster, OLTP cluster, Storage cluster ( SQL , redis, CDN etc) and cloud native cluster.

 

 

 

Wenhui 

 

On Sun, Feb 20, 2022, 8:07 AM Elana Copperman <Elana.Copperman@...> wrote:

Good points, thanks Wenhui.

If you can help to collect more feedback and generate interest from additional practitioners, we can help to build a community within ELISA who can work with the LF on such goals.

 

From: devel@... <devel@...> On Behalf Of Wenhui Zhang
Sent: Wednesday, February 16, 2022 7:02 PM
To: Elana Copperman <Elana.Copperman@...>
Cc: Smith, Jason <Jason.Smith@...>; Lukas Bulwahn <lukas.bulwahn@...>; Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

As practitioners in industry who uses Linux for the cloud infrastructure, we are very interested in what are the mandatory kernel configurations , and what safety purpose these kernel configurations are for, so that we could learn and configure Linux in the right way.

 

Also, we are not using the current Linux kernel version.  We are  interested in  safety patches to Linux kernel we should backwards ported to our Linux version.

 

On Wed, Feb 16, 2022, 8:22 AM <elana.copperman@...> wrote:

Hi all,

A point to consider when choosing tasks:  perhaps we should define clear criteria, based on potential benefit to the community - and include that message in the introduction or overview.  Then try to focus on those tasks with highest potential benefit.

I am finding it difficult even to understand the intent or purpose of some of these documents.

Elana

 


From: Smith, Jason <Jason.Smith@...>
Sent: Wednesday, February 16, 2022 6:17 PM
To: Lukas Bulwahn <lukas.bulwahn@...>
Cc: Elana Copperman <Elana.Copperman@...>; Shuah Khan <skhan@...>; devel@... <devel@...>
Subject: RE: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

Hi Lukas,

Thanks for your reply.

I missed the very end of today's meeting (apologies to all for having to drop off the call before it concluded) so I'm not sure if and how much this was discussed further, but even some of the items you identified below that are "difficult" may not be so much if the efforts are constrained to a specific feature of Linux or are meta/high-level in nature.

Specific to your most recent message, the one item that I think would be useful to those who are just looking to create a safer system using Linux, or are looking to use Linux in the context of a system that requires conformance with a safety standard that allows treating Software of Unknown Pedigree (SOUP) as-is, would be release notes that document what are the known issues with Linux - whether they be of the nature of "don't do this; it's not a bug/defect, but if you implement something this way, you will get bad results" or actual, genuine software defects or bugs.

Unfortunately, I'm going to be off work during the next workshop in April and will not be able to present on any topics, so it'll be important for me to keep talking about these topics during our weekly meetings to keep momentum going.

Jason


-----Original Message-----
From: Lukas Bulwahn <lukas.bulwahn@...>
Sent: Wednesday, February 16, 2022 10:05 AM
To: Lukas Bulwahn <lukas.bulwahn@...>
Cc: Smith, Jason <Jason.Smith@...>; elana.copperman@...; Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

On Wed, Feb 16, 2022 at 3:13 PM Lukas Bulwahn via lists.elisa.tech <lukas.bulwahn=gmail.com@...> wrote:
>
> On Wed, Feb 16, 2022 at 2:49 PM Smith, Jason <Jason.Smith@...> wrote:
> >
> > A quick reply to Lukas prior to our meeting (I apologize, didn't have time to prioritize):
> >
> > We should revisit the work I/we started to do two years ago that never really materialized into anything, which is partially if not completely my own fault; conclusions from the third draft of the white paper I was working on:
> >
>
> Just a quick assessment:
>
> > - Manual, including general information pertaining to the Linux distribution like the version/revision and descriptions of APIs, etc.
>
> "Easy"(TM, final last words...) --- let us try to present you something here.
>
> > - Fault Analysis, identifying general risks associated with the use
> > of Linux and how those risks have been (or should be) addressed
>
> Difficult. What is a general risk? What is the system? Who needs to
> address? (I do not know what to do...) --- let us postpone.
>
> > - Design Guide, providing recommendations for appropriate hardware
> > and software architectures to use for safety applications
>
> Difficult. Again, needs an assumption on a system --- let us postpone.
>
> > - Verification and Validation Report, describing the procedures,
> > methods, and criteria used to develop and test that Linux
> > distribution prior to its release, and the results of those tests
>
> "Easy"(TM, final last words...) --- let us try to present you something here.
>
> > - Release Notes, describing any known issues or bugs in that
> > particular Linux distribution
>
> "Easy"(TM, final last words...) --- let us try to present you something here.
>
> Would you see some priority on the easy-marked ones and would you
> accept to postpone the two difficult ones?
>

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,

Lukas

> Then, I could present some "examples" for the easy results, and see
> where we go from there.
>
> Lukas
>
>
> >
> > Jason
> >
> > -----Original Message-----
> > From: Lukas Bulwahn <lukas.bulwahn@...>
> > Sent: Wednesday, February 16, 2022 7:38 AM
> > To: Smith, Jason <Jason.Smith@...>
> > Cc: elana.copperman@...; Shuah Khan
> > <skhan@...>; devel@...
> > Subject: Re: [ELISA Technical Community] TSC Meeting Agenda -
> > February 16 2022
> >
> > On Thu, Feb 10, 2022 at 4:29 AM Smith, Jason via lists.elisa.tech <jason.smith=ul.com@...> wrote:
> > >
> > > My goals are quick wins.  There are safety applications using Linux that either don't need safety certification or whose standards allow Linux to be treated as-is, i.e. software of unknown pedigree.  Just small improvements to Linux or relatively small additional pieces of information provided with Linux could offer a lot of value to these developers, allowing them to build safer products.  Examples: code improvements, new modules that add or support software safety measures, white papers, manuals, design guides, fault analyses, reports (verification, validation, review, etc.), release notes including known issues, etc.  In a way, this is perhaps a scaled-down version of Elana's (3).
> > >
> >
> > 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 prioritized list?
> >
> > Then, we could start at the top of that list and present an example of such pieces of information and discuss them with you to determine the potential effort of providing such information regularly (e.g., for every version) and completely (not just as some incomplete example for the purpose of having a discussion).
> >
> > I would like to contribute to creating that you see as quick wins. For me, there is nothing to lose here.
> >
> >
> > Lukas
> >
> > >
> > >
> > > That being said... I don't know if this is exactly what the community needs.
> > >
> > >
> > >
> > > I think (if we haven't done so already) we should go out far and wide across not only ELISA but Linux developers in general to find out what they really need.
> > >
> > >
> > >
> > > Are there enough developers of safety applications using Linux that are okay with treating Linux as-is, making it worthwhile to pursue my stated goal?
> > >
> > >
> > >
> > > Or are most folks trying to develop systems for self-driving cars using Linux and ultimately need compliance with ISO 26262?
> > >
> > >
> > >
> > > If the latter is true, start with Elana's (1).  It's going to be a lot of work.
> > >
> > >
> > >
> > > Jason
> > >
> > >
> > >
> > > From: devel@... <devel@...> On Behalf Of
> > > elana.copperman via lists.elisa.tech
> > > Sent: Wednesday, February 09, 2022 9:37 AM
> > > To: Shuah Khan <skhan@...>; devel@...
> > > Subject: Re: [ELISA Technical Community] TSC Meeting Agenda -
> > > February
> > > 16 2022
> > >
> > >
> > >
> > > Thanks, Shuah.  Some goals/ideas from my side:
> > >
> > > To establish a framework for communication and collaboration between Linux kernel developers/maintainers, safety experts and designers/developers of Linux based safety critical systems.  Without broader representation and communication, the work products of ELISA cannot have a context for deployment and acceptance.
> > > ELISA is a project of the Linux Foundation.  To leverage this umbrella, learn from its strong points, and help to improve the weaker points towards the long-term goal of integrating Linux successfully in safety critical systems.
> > > Work products (actual kernel patches) which will support the original ELISA mission statement:   to define and maintain a common set of elements, processes and tools that can be incorporated into Linux-based, safety-critical systems amenable to safety certification.
> > >
> > > Regards
> > >
> > > Elana
> > >
> > > ________________________________
> > >
> > > From: devel@... <devel@...> on behalf of
> > > Shuah Khan <skhan@...>
> > > Sent: Wednesday, February 9, 2022 5:20 PM
> > > To: devel@... <devel@...>
> > > Cc: Shuah Khan <skhan@...>
> > > Subject: [ELISA Technical Community] TSC Meeting Agenda - February
> > > 16
> > > 2022
> > >
> > >
> > >
> > > EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.
> > >
> > > All,
> > >
> > > Let's meet next week to discuss alignment on goals and what
> > > success looks like. Please respond to this thread to add you 1 or
> > > 2 items you consider important to achieve ELISA goals and make the
> > > project successful.
> > >
> > > I will compile the items and share the consolidated list before
> > > the meeting.
> > >
> > > thanks,
> > > -- Shuah
> > >
> > >
> > >
> > >
> > >
> > >
> > > This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
> > >
> > >
> >
> > This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
>
>
>
>
>

This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.


elana.copperman@...
 

Thanks, Wenhui.

Would it be possible for someone who speaks English reasonably well to join the meeting tomorrow, and to clarify for the group what specific requirements could be focused?  This would be an interesting way to get practical feedback to guide our work.

Regards

Elana

 

From: Wenhui Zhang <wenhuizhang.psu@...>
Sent: Sunday, February 20, 2022 6:36 PM
To: Elana Copperman <Elana.Copperman@...>
Cc: Smith, Jason <Jason.Smith@...>; Lukas Bulwahn <lukas.bulwahn@...>; Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

Hi, Elana

 

We discussed with China Team of TikTok for what we would like to learn.

 

Linux safety Configurations' usage , guarantees and performance tradeoffs. 

 

The recommendation for Linux safety configurations  both guest os in private cloud, guest os in public cloud, Host os in private cloud and host os in public cloud. 

 

 

The recommendation for Linux safety configurations for OLAP cluster, OLTP cluster, Storage cluster ( SQL , redis, CDN etc) and cloud native cluster.

 

 

 

Wenhui 

 

On Sun, Feb 20, 2022, 8:07 AM Elana Copperman <Elana.Copperman@...> wrote:

Good points, thanks Wenhui.

If you can help to collect more feedback and generate interest from additional practitioners, we can help to build a community within ELISA who can work with the LF on such goals.

 

From: devel@... <devel@...> On Behalf Of Wenhui Zhang
Sent: Wednesday, February 16, 2022 7:02 PM
To: Elana Copperman <Elana.Copperman@...>
Cc: Smith, Jason <Jason.Smith@...>; Lukas Bulwahn <lukas.bulwahn@...>; Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

As practitioners in industry who uses Linux for the cloud infrastructure, we are very interested in what are the mandatory kernel configurations , and what safety purpose these kernel configurations are for, so that we could learn and configure Linux in the right way.

 

Also, we are not using the current Linux kernel version.  We are  interested in  safety patches to Linux kernel we should backwards ported to our Linux version.

 

On Wed, Feb 16, 2022, 8:22 AM <elana.copperman@...> wrote:

Hi all,

A point to consider when choosing tasks:  perhaps we should define clear criteria, based on potential benefit to the community - and include that message in the introduction or overview.  Then try to focus on those tasks with highest potential benefit.

I am finding it difficult even to understand the intent or purpose of some of these documents.

Elana

 


From: Smith, Jason <Jason.Smith@...>
Sent: Wednesday, February 16, 2022 6:17 PM
To: Lukas Bulwahn <lukas.bulwahn@...>
Cc: Elana Copperman <Elana.Copperman@...>; Shuah Khan <skhan@...>; devel@... <devel@...>
Subject: RE: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

Hi Lukas,

Thanks for your reply.

I missed the very end of today's meeting (apologies to all for having to drop off the call before it concluded) so I'm not sure if and how much this was discussed further, but even some of the items you identified below that are "difficult" may not be so much if the efforts are constrained to a specific feature of Linux or are meta/high-level in nature.

Specific to your most recent message, the one item that I think would be useful to those who are just looking to create a safer system using Linux, or are looking to use Linux in the context of a system that requires conformance with a safety standard that allows treating Software of Unknown Pedigree (SOUP) as-is, would be release notes that document what are the known issues with Linux - whether they be of the nature of "don't do this; it's not a bug/defect, but if you implement something this way, you will get bad results" or actual, genuine software defects or bugs.

Unfortunately, I'm going to be off work during the next workshop in April and will not be able to present on any topics, so it'll be important for me to keep talking about these topics during our weekly meetings to keep momentum going.

Jason


-----Original Message-----
From: Lukas Bulwahn <lukas.bulwahn@...>
Sent: Wednesday, February 16, 2022 10:05 AM
To: Lukas Bulwahn <lukas.bulwahn@...>
Cc: Smith, Jason <Jason.Smith@...>; elana.copperman@...; Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

On Wed, Feb 16, 2022 at 3:13 PM Lukas Bulwahn via lists.elisa.tech <lukas.bulwahn=gmail.com@...> wrote:
>
> On Wed, Feb 16, 2022 at 2:49 PM Smith, Jason <Jason.Smith@...> wrote:
> >
> > A quick reply to Lukas prior to our meeting (I apologize, didn't have time to prioritize):
> >
> > We should revisit the work I/we started to do two years ago that never really materialized into anything, which is partially if not completely my own fault; conclusions from the third draft of the white paper I was working on:
> >
>
> Just a quick assessment:
>
> > - Manual, including general information pertaining to the Linux distribution like the version/revision and descriptions of APIs, etc.
>
> "Easy"(TM, final last words...) --- let us try to present you something here.
>
> > - Fault Analysis, identifying general risks associated with the use
> > of Linux and how those risks have been (or should be) addressed
>
> Difficult. What is a general risk? What is the system? Who needs to
> address? (I do not know what to do...) --- let us postpone.
>
> > - Design Guide, providing recommendations for appropriate hardware
> > and software architectures to use for safety applications
>
> Difficult. Again, needs an assumption on a system --- let us postpone.
>
> > - Verification and Validation Report, describing the procedures,
> > methods, and criteria used to develop and test that Linux
> > distribution prior to its release, and the results of those tests
>
> "Easy"(TM, final last words...) --- let us try to present you something here.
>
> > - Release Notes, describing any known issues or bugs in that
> > particular Linux distribution
>
> "Easy"(TM, final last words...) --- let us try to present you something here.
>
> Would you see some priority on the easy-marked ones and would you
> accept to postpone the two difficult ones?
>

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,

Lukas

> Then, I could present some "examples" for the easy results, and see
> where we go from there.
>
> Lukas
>
>
> >
> > Jason
> >
> > -----Original Message-----
> > From: Lukas Bulwahn <lukas.bulwahn@...>
> > Sent: Wednesday, February 16, 2022 7:38 AM
> > To: Smith, Jason <Jason.Smith@...>
> > Cc: elana.copperman@...; Shuah Khan
> > <skhan@...>; devel@...
> > Subject: Re: [ELISA Technical Community] TSC Meeting Agenda -
> > February 16 2022
> >
> > On Thu, Feb 10, 2022 at 4:29 AM Smith, Jason via lists.elisa.tech <jason.smith=ul.com@...> wrote:
> > >
> > > My goals are quick wins.  There are safety applications using Linux that either don't need safety certification or whose standards allow Linux to be treated as-is, i.e. software of unknown pedigree.  Just small improvements to Linux or relatively small additional pieces of information provided with Linux could offer a lot of value to these developers, allowing them to build safer products.  Examples: code improvements, new modules that add or support software safety measures, white papers, manuals, design guides, fault analyses, reports (verification, validation, review, etc.), release notes including known issues, etc.  In a way, this is perhaps a scaled-down version of Elana's (3).
> > >
> >
> > 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 prioritized list?
> >
> > Then, we could start at the top of that list and present an example of such pieces of information and discuss them with you to determine the potential effort of providing such information regularly (e.g., for every version) and completely (not just as some incomplete example for the purpose of having a discussion).
> >
> > I would like to contribute to creating that you see as quick wins. For me, there is nothing to lose here.
> >
> >
> > Lukas
> >
> > >
> > >
> > > That being said... I don't know if this is exactly what the community needs.
> > >
> > >
> > >
> > > I think (if we haven't done so already) we should go out far and wide across not only ELISA but Linux developers in general to find out what they really need.
> > >
> > >
> > >
> > > Are there enough developers of safety applications using Linux that are okay with treating Linux as-is, making it worthwhile to pursue my stated goal?
> > >
> > >
> > >
> > > Or are most folks trying to develop systems for self-driving cars using Linux and ultimately need compliance with ISO 26262?
> > >
> > >
> > >
> > > If the latter is true, start with Elana's (1).  It's going to be a lot of work.
> > >
> > >
> > >
> > > Jason
> > >
> > >
> > >
> > > From: devel@... <devel@...> On Behalf Of
> > > elana.copperman via lists.elisa.tech
> > > Sent: Wednesday, February 09, 2022 9:37 AM
> > > To: Shuah Khan <skhan@...>; devel@...
> > > Subject: Re: [ELISA Technical Community] TSC Meeting Agenda -
> > > February
> > > 16 2022
> > >
> > >
> > >
> > > Thanks, Shuah.  Some goals/ideas from my side:
> > >
> > > To establish a framework for communication and collaboration between Linux kernel developers/maintainers, safety experts and designers/developers of Linux based safety critical systems.  Without broader representation and communication, the work products of ELISA cannot have a context for deployment and acceptance.
> > > ELISA is a project of the Linux Foundation.  To leverage this umbrella, learn from its strong points, and help to improve the weaker points towards the long-term goal of integrating Linux successfully in safety critical systems.
> > > Work products (actual kernel patches) which will support the original ELISA mission statement:   to define and maintain a common set of elements, processes and tools that can be incorporated into Linux-based, safety-critical systems amenable to safety certification.
> > >
> > > Regards
> > >
> > > Elana
> > >
> > > ________________________________
> > >
> > > From: devel@... <devel@...> on behalf of
> > > Shuah Khan <skhan@...>
> > > Sent: Wednesday, February 9, 2022 5:20 PM
> > > To: devel@... <devel@...>
> > > Cc: Shuah Khan <skhan@...>
> > > Subject: [ELISA Technical Community] TSC Meeting Agenda - February
> > > 16
> > > 2022
> > >
> > >
> > >
> > > EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.
> > >
> > > All,
> > >
> > > Let's meet next week to discuss alignment on goals and what
> > > success looks like. Please respond to this thread to add you 1 or
> > > 2 items you consider important to achieve ELISA goals and make the
> > > project successful.
> > >
> > > I will compile the items and share the consolidated list before
> > > the meeting.
> > >
> > > thanks,
> > > -- Shuah
> > >
> > >
> > >
> > >
> > >
> > >
> > > This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
> > >
> > >
> >
> > This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
>
>
>
>
>

This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.


Wenhui Zhang
 

Hi, Elana:

We discussed with China Team of TikTok for what we would like to learn.

Linux safety Configurations' usage , guarantees and performance tradeoffs. 

The recommendation for Linux safety configurations  both guest os in private cloud, guest os in public cloud, Host os in private cloud and host os in public cloud. 


The recommendation for Linux safety configurations for OLAP cluster, OLTP cluster, Storage cluster ( SQL , redis, CDN etc) and cloud native cluster.



Wenhui 

On Sun, Feb 20, 2022, 8:07 AM Elana Copperman <Elana.Copperman@...> wrote:

Good points, thanks Wenhui.

If you can help to collect more feedback and generate interest from additional practitioners, we can help to build a community within ELISA who can work with the LF on such goals.

 

From: devel@... <devel@...> On Behalf Of Wenhui Zhang
Sent: Wednesday, February 16, 2022 7:02 PM
To: Elana Copperman <Elana.Copperman@...>
Cc: Smith, Jason <Jason.Smith@...>; Lukas Bulwahn <lukas.bulwahn@...>; Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

As practitioners in industry who uses Linux for the cloud infrastructure, we are very interested in what are the mandatory kernel configurations , and what safety purpose these kernel configurations are for, so that we could learn and configure Linux in the right way.

 

Also, we are not using the current Linux kernel version.  We are  interested in  safety patches to Linux kernel we should backwards ported to our Linux version.

 

On Wed, Feb 16, 2022, 8:22 AM <elana.copperman@...> wrote:

Hi all,

A point to consider when choosing tasks:  perhaps we should define clear criteria, based on potential benefit to the community - and include that message in the introduction or overview.  Then try to focus on those tasks with highest potential benefit.

I am finding it difficult even to understand the intent or purpose of some of these documents.

Elana

 


From: Smith, Jason <Jason.Smith@...>
Sent: Wednesday, February 16, 2022 6:17 PM
To: Lukas Bulwahn <lukas.bulwahn@...>
Cc: Elana Copperman <Elana.Copperman@...>; Shuah Khan <skhan@...>; devel@... <devel@...>
Subject: RE: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

Hi Lukas,

Thanks for your reply.

I missed the very end of today's meeting (apologies to all for having to drop off the call before it concluded) so I'm not sure if and how much this was discussed further, but even some of the items you identified below that are "difficult" may not be so much if the efforts are constrained to a specific feature of Linux or are meta/high-level in nature.

Specific to your most recent message, the one item that I think would be useful to those who are just looking to create a safer system using Linux, or are looking to use Linux in the context of a system that requires conformance with a safety standard that allows treating Software of Unknown Pedigree (SOUP) as-is, would be release notes that document what are the known issues with Linux - whether they be of the nature of "don't do this; it's not a bug/defect, but if you implement something this way, you will get bad results" or actual, genuine software defects or bugs.

Unfortunately, I'm going to be off work during the next workshop in April and will not be able to present on any topics, so it'll be important for me to keep talking about these topics during our weekly meetings to keep momentum going.

Jason


-----Original Message-----
From: Lukas Bulwahn <lukas.bulwahn@...>
Sent: Wednesday, February 16, 2022 10:05 AM
To: Lukas Bulwahn <lukas.bulwahn@...>
Cc: Smith, Jason <Jason.Smith@...>; elana.copperman@...; Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

On Wed, Feb 16, 2022 at 3:13 PM Lukas Bulwahn via lists.elisa.tech <lukas.bulwahn=gmail.com@...> wrote:
>
> On Wed, Feb 16, 2022 at 2:49 PM Smith, Jason <Jason.Smith@...> wrote:
> >
> > A quick reply to Lukas prior to our meeting (I apologize, didn't have time to prioritize):
> >
> > We should revisit the work I/we started to do two years ago that never really materialized into anything, which is partially if not completely my own fault; conclusions from the third draft of the white paper I was working on:
> >
>
> Just a quick assessment:
>
> > - Manual, including general information pertaining to the Linux distribution like the version/revision and descriptions of APIs, etc.
>
> "Easy"(TM, final last words...) --- let us try to present you something here.
>
> > - Fault Analysis, identifying general risks associated with the use
> > of Linux and how those risks have been (or should be) addressed
>
> Difficult. What is a general risk? What is the system? Who needs to
> address? (I do not know what to do...) --- let us postpone.
>
> > - Design Guide, providing recommendations for appropriate hardware
> > and software architectures to use for safety applications
>
> Difficult. Again, needs an assumption on a system --- let us postpone.
>
> > - Verification and Validation Report, describing the procedures,
> > methods, and criteria used to develop and test that Linux
> > distribution prior to its release, and the results of those tests
>
> "Easy"(TM, final last words...) --- let us try to present you something here.
>
> > - Release Notes, describing any known issues or bugs in that
> > particular Linux distribution
>
> "Easy"(TM, final last words...) --- let us try to present you something here.
>
> Would you see some priority on the easy-marked ones and would you
> accept to postpone the two difficult ones?
>

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,

Lukas

> Then, I could present some "examples" for the easy results, and see
> where we go from there.
>
> Lukas
>
>
> >
> > Jason
> >
> > -----Original Message-----
> > From: Lukas Bulwahn <lukas.bulwahn@...>
> > Sent: Wednesday, February 16, 2022 7:38 AM
> > To: Smith, Jason <Jason.Smith@...>
> > Cc: elana.copperman@...; Shuah Khan
> > <skhan@...>; devel@...
> > Subject: Re: [ELISA Technical Community] TSC Meeting Agenda -
> > February 16 2022
> >
> > On Thu, Feb 10, 2022 at 4:29 AM Smith, Jason via lists.elisa.tech <jason.smith=ul.com@...> wrote:
> > >
> > > My goals are quick wins.  There are safety applications using Linux that either don't need safety certification or whose standards allow Linux to be treated as-is, i.e. software of unknown pedigree.  Just small improvements to Linux or relatively small additional pieces of information provided with Linux could offer a lot of value to these developers, allowing them to build safer products.  Examples: code improvements, new modules that add or support software safety measures, white papers, manuals, design guides, fault analyses, reports (verification, validation, review, etc.), release notes including known issues, etc.  In a way, this is perhaps a scaled-down version of Elana's (3).
> > >
> >
> > 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 prioritized list?
> >
> > Then, we could start at the top of that list and present an example of such pieces of information and discuss them with you to determine the potential effort of providing such information regularly (e.g., for every version) and completely (not just as some incomplete example for the purpose of having a discussion).
> >
> > I would like to contribute to creating that you see as quick wins. For me, there is nothing to lose here.
> >
> >
> > Lukas
> >
> > >
> > >
> > > That being said... I don't know if this is exactly what the community needs.
> > >
> > >
> > >
> > > I think (if we haven't done so already) we should go out far and wide across not only ELISA but Linux developers in general to find out what they really need.
> > >
> > >
> > >
> > > Are there enough developers of safety applications using Linux that are okay with treating Linux as-is, making it worthwhile to pursue my stated goal?
> > >
> > >
> > >
> > > Or are most folks trying to develop systems for self-driving cars using Linux and ultimately need compliance with ISO 26262?
> > >
> > >
> > >
> > > If the latter is true, start with Elana's (1).  It's going to be a lot of work.
> > >
> > >
> > >
> > > Jason
> > >
> > >
> > >
> > > From: devel@... <devel@...> On Behalf Of
> > > elana.copperman via lists.elisa.tech
> > > Sent: Wednesday, February 09, 2022 9:37 AM
> > > To: Shuah Khan <skhan@...>; devel@...
> > > Subject: Re: [ELISA Technical Community] TSC Meeting Agenda -
> > > February
> > > 16 2022
> > >
> > >
> > >
> > > Thanks, Shuah.  Some goals/ideas from my side:
> > >
> > > To establish a framework for communication and collaboration between Linux kernel developers/maintainers, safety experts and designers/developers of Linux based safety critical systems.  Without broader representation and communication, the work products of ELISA cannot have a context for deployment and acceptance.
> > > ELISA is a project of the Linux Foundation.  To leverage this umbrella, learn from its strong points, and help to improve the weaker points towards the long-term goal of integrating Linux successfully in safety critical systems.
> > > Work products (actual kernel patches) which will support the original ELISA mission statement:   to define and maintain a common set of elements, processes and tools that can be incorporated into Linux-based, safety-critical systems amenable to safety certification.
> > >
> > > Regards
> > >
> > > Elana
> > >
> > > ________________________________
> > >
> > > From: devel@... <devel@...> on behalf of
> > > Shuah Khan <skhan@...>
> > > Sent: Wednesday, February 9, 2022 5:20 PM
> > > To: devel@... <devel@...>
> > > Cc: Shuah Khan <skhan@...>
> > > Subject: [ELISA Technical Community] TSC Meeting Agenda - February
> > > 16
> > > 2022
> > >
> > >
> > >
> > > EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.
> > >
> > > All,
> > >
> > > Let's meet next week to discuss alignment on goals and what
> > > success looks like. Please respond to this thread to add you 1 or
> > > 2 items you consider important to achieve ELISA goals and make the
> > > project successful.
> > >
> > > I will compile the items and share the consolidated list before
> > > the meeting.
> > >
> > > thanks,
> > > -- Shuah
> > >
> > >
> > >
> > >
> > >
> > >
> > > This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
> > >
> > >
> >
> > This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
>
>
>
>
>

This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.


elana.copperman@...
 

Good points, thanks Wenhui.

If you can help to collect more feedback and generate interest from additional practitioners, we can help to build a community within ELISA who can work with the LF on such goals.

 

From: devel@... <devel@...> On Behalf Of Wenhui Zhang
Sent: Wednesday, February 16, 2022 7:02 PM
To: Elana Copperman <Elana.Copperman@...>
Cc: Smith, Jason <Jason.Smith@...>; Lukas Bulwahn <lukas.bulwahn@...>; Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

As practitioners in industry who uses Linux for the cloud infrastructure, we are very interested in what are the mandatory kernel configurations , and what safety purpose these kernel configurations are for, so that we could learn and configure Linux in the right way.

 

Also, we are not using the current Linux kernel version.  We are  interested in  safety patches to Linux kernel we should backwards ported to our Linux version.

 

On Wed, Feb 16, 2022, 8:22 AM <elana.copperman@...> wrote:

Hi all,

A point to consider when choosing tasks:  perhaps we should define clear criteria, based on potential benefit to the community - and include that message in the introduction or overview.  Then try to focus on those tasks with highest potential benefit.

I am finding it difficult even to understand the intent or purpose of some of these documents.

Elana

 


From: Smith, Jason <Jason.Smith@...>
Sent: Wednesday, February 16, 2022 6:17 PM
To: Lukas Bulwahn <lukas.bulwahn@...>
Cc: Elana Copperman <Elana.Copperman@...>; Shuah Khan <skhan@...>; devel@... <devel@...>
Subject: RE: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

Hi Lukas,

Thanks for your reply.

I missed the very end of today's meeting (apologies to all for having to drop off the call before it concluded) so I'm not sure if and how much this was discussed further, but even some of the items you identified below that are "difficult" may not be so much if the efforts are constrained to a specific feature of Linux or are meta/high-level in nature.

Specific to your most recent message, the one item that I think would be useful to those who are just looking to create a safer system using Linux, or are looking to use Linux in the context of a system that requires conformance with a safety standard that allows treating Software of Unknown Pedigree (SOUP) as-is, would be release notes that document what are the known issues with Linux - whether they be of the nature of "don't do this; it's not a bug/defect, but if you implement something this way, you will get bad results" or actual, genuine software defects or bugs.

Unfortunately, I'm going to be off work during the next workshop in April and will not be able to present on any topics, so it'll be important for me to keep talking about these topics during our weekly meetings to keep momentum going.

Jason


-----Original Message-----
From: Lukas Bulwahn <lukas.bulwahn@...>
Sent: Wednesday, February 16, 2022 10:05 AM
To: Lukas Bulwahn <lukas.bulwahn@...>
Cc: Smith, Jason <Jason.Smith@...>; elana.copperman@...; Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

On Wed, Feb 16, 2022 at 3:13 PM Lukas Bulwahn via lists.elisa.tech <lukas.bulwahn=gmail.com@...> wrote:
>
> On Wed, Feb 16, 2022 at 2:49 PM Smith, Jason <Jason.Smith@...> wrote:
> >
> > A quick reply to Lukas prior to our meeting (I apologize, didn't have time to prioritize):
> >
> > We should revisit the work I/we started to do two years ago that never really materialized into anything, which is partially if not completely my own fault; conclusions from the third draft of the white paper I was working on:
> >
>
> Just a quick assessment:
>
> > - Manual, including general information pertaining to the Linux distribution like the version/revision and descriptions of APIs, etc.
>
> "Easy"(TM, final last words...) --- let us try to present you something here.
>
> > - Fault Analysis, identifying general risks associated with the use
> > of Linux and how those risks have been (or should be) addressed
>
> Difficult. What is a general risk? What is the system? Who needs to
> address? (I do not know what to do...) --- let us postpone.
>
> > - Design Guide, providing recommendations for appropriate hardware
> > and software architectures to use for safety applications
>
> Difficult. Again, needs an assumption on a system --- let us postpone.
>
> > - Verification and Validation Report, describing the procedures,
> > methods, and criteria used to develop and test that Linux
> > distribution prior to its release, and the results of those tests
>
> "Easy"(TM, final last words...) --- let us try to present you something here.
>
> > - Release Notes, describing any known issues or bugs in that
> > particular Linux distribution
>
> "Easy"(TM, final last words...) --- let us try to present you something here.
>
> Would you see some priority on the easy-marked ones and would you
> accept to postpone the two difficult ones?
>

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,

Lukas

> Then, I could present some "examples" for the easy results, and see
> where we go from there.
>
> Lukas
>
>
> >
> > Jason
> >
> > -----Original Message-----
> > From: Lukas Bulwahn <lukas.bulwahn@...>
> > Sent: Wednesday, February 16, 2022 7:38 AM
> > To: Smith, Jason <Jason.Smith@...>
> > Cc: elana.copperman@...; Shuah Khan
> > <skhan@...>; devel@...
> > Subject: Re: [ELISA Technical Community] TSC Meeting Agenda -
> > February 16 2022
> >
> > On Thu, Feb 10, 2022 at 4:29 AM Smith, Jason via lists.elisa.tech <jason.smith=ul.com@...> wrote:
> > >
> > > My goals are quick wins.  There are safety applications using Linux that either don't need safety certification or whose standards allow Linux to be treated as-is, i.e. software of unknown pedigree.  Just small improvements to Linux or relatively small additional pieces of information provided with Linux could offer a lot of value to these developers, allowing them to build safer products.  Examples: code improvements, new modules that add or support software safety measures, white papers, manuals, design guides, fault analyses, reports (verification, validation, review, etc.), release notes including known issues, etc.  In a way, this is perhaps a scaled-down version of Elana's (3).
> > >
> >
> > 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 prioritized list?
> >
> > Then, we could start at the top of that list and present an example of such pieces of information and discuss them with you to determine the potential effort of providing such information regularly (e.g., for every version) and completely (not just as some incomplete example for the purpose of having a discussion).
> >
> > I would like to contribute to creating that you see as quick wins. For me, there is nothing to lose here.
> >
> >
> > Lukas
> >
> > >
> > >
> > > That being said... I don't know if this is exactly what the community needs.
> > >
> > >
> > >
> > > I think (if we haven't done so already) we should go out far and wide across not only ELISA but Linux developers in general to find out what they really need.
> > >
> > >
> > >
> > > Are there enough developers of safety applications using Linux that are okay with treating Linux as-is, making it worthwhile to pursue my stated goal?
> > >
> > >
> > >
> > > Or are most folks trying to develop systems for self-driving cars using Linux and ultimately need compliance with ISO 26262?
> > >
> > >
> > >
> > > If the latter is true, start with Elana's (1).  It's going to be a lot of work.
> > >
> > >
> > >
> > > Jason
> > >
> > >
> > >
> > > From: devel@... <devel@...> On Behalf Of
> > > elana.copperman via lists.elisa.tech
> > > Sent: Wednesday, February 09, 2022 9:37 AM
> > > To: Shuah Khan <skhan@...>; devel@...
> > > Subject: Re: [ELISA Technical Community] TSC Meeting Agenda -
> > > February
> > > 16 2022
> > >
> > >
> > >
> > > Thanks, Shuah.  Some goals/ideas from my side:
> > >
> > > To establish a framework for communication and collaboration between Linux kernel developers/maintainers, safety experts and designers/developers of Linux based safety critical systems.  Without broader representation and communication, the work products of ELISA cannot have a context for deployment and acceptance.
> > > ELISA is a project of the Linux Foundation.  To leverage this umbrella, learn from its strong points, and help to improve the weaker points towards the long-term goal of integrating Linux successfully in safety critical systems.
> > > Work products (actual kernel patches) which will support the original ELISA mission statement:   to define and maintain a common set of elements, processes and tools that can be incorporated into Linux-based, safety-critical systems amenable to safety certification.
> > >
> > > Regards
> > >
> > > Elana
> > >
> > > ________________________________
> > >
> > > From: devel@... <devel@...> on behalf of
> > > Shuah Khan <skhan@...>
> > > Sent: Wednesday, February 9, 2022 5:20 PM
> > > To: devel@... <devel@...>
> > > Cc: Shuah Khan <skhan@...>
> > > Subject: [ELISA Technical Community] TSC Meeting Agenda - February
> > > 16
> > > 2022
> > >
> > >
> > >
> > > EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.
> > >
> > > All,
> > >
> > > Let's meet next week to discuss alignment on goals and what
> > > success looks like. Please respond to this thread to add you 1 or
> > > 2 items you consider important to achieve ELISA goals and make the
> > > project successful.
> > >
> > > I will compile the items and share the consolidated list before
> > > the meeting.
> > >
> > > thanks,
> > > -- Shuah
> > >
> > >
> > >
> > >
> > >
> > >
> > > This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
> > >
> > >
> >
> > This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
>
>
>
>
>

This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.


Wenhui Zhang
 

As practitioners in industry who uses Linux for the cloud infrastructure, we are very interested in what are the mandatory kernel configurations , and what safety purpose these kernel configurations are for, so that we could learn and configure Linux in the right way.

Also, we are not using the current Linux kernel version.  We are  interested in  safety patches to Linux kernel we should backwards ported to our Linux version.

On Wed, Feb 16, 2022, 8:22 AM <elana.copperman@...> wrote:
Hi all,
A point to consider when choosing tasks:  perhaps we should define clear criteria, based on potential benefit to the community - and include that message in the introduction or overview.  Then try to focus on those tasks with highest potential benefit.
I am finding it difficult even to understand the intent or purpose of some of these documents.
Elana


From: Smith, Jason <Jason.Smith@...>
Sent: Wednesday, February 16, 2022 6:17 PM
To: Lukas Bulwahn <lukas.bulwahn@...>
Cc: Elana Copperman <Elana.Copperman@...>; Shuah Khan <skhan@...>; devel@... <devel@...>
Subject: RE: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022
 
EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

Hi Lukas,

Thanks for your reply.

I missed the very end of today's meeting (apologies to all for having to drop off the call before it concluded) so I'm not sure if and how much this was discussed further, but even some of the items you identified below that are "difficult" may not be so much if the efforts are constrained to a specific feature of Linux or are meta/high-level in nature.

Specific to your most recent message, the one item that I think would be useful to those who are just looking to create a safer system using Linux, or are looking to use Linux in the context of a system that requires conformance with a safety standard that allows treating Software of Unknown Pedigree (SOUP) as-is, would be release notes that document what are the known issues with Linux - whether they be of the nature of "don't do this; it's not a bug/defect, but if you implement something this way, you will get bad results" or actual, genuine software defects or bugs.

Unfortunately, I'm going to be off work during the next workshop in April and will not be able to present on any topics, so it'll be important for me to keep talking about these topics during our weekly meetings to keep momentum going.

Jason


-----Original Message-----
From: Lukas Bulwahn <lukas.bulwahn@...>
Sent: Wednesday, February 16, 2022 10:05 AM
To: Lukas Bulwahn <lukas.bulwahn@...>
Cc: Smith, Jason <Jason.Smith@...>; elana.copperman@...; Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

On Wed, Feb 16, 2022 at 3:13 PM Lukas Bulwahn via lists.elisa.tech <lukas.bulwahn=gmail.com@...> wrote:
>
> On Wed, Feb 16, 2022 at 2:49 PM Smith, Jason <Jason.Smith@...> wrote:
> >
> > A quick reply to Lukas prior to our meeting (I apologize, didn't have time to prioritize):
> >
> > We should revisit the work I/we started to do two years ago that never really materialized into anything, which is partially if not completely my own fault; conclusions from the third draft of the white paper I was working on:
> >
>
> Just a quick assessment:
>
> > - Manual, including general information pertaining to the Linux distribution like the version/revision and descriptions of APIs, etc.
>
> "Easy"(TM, final last words...) --- let us try to present you something here.
>
> > - Fault Analysis, identifying general risks associated with the use
> > of Linux and how those risks have been (or should be) addressed
>
> Difficult. What is a general risk? What is the system? Who needs to
> address? (I do not know what to do...) --- let us postpone.
>
> > - Design Guide, providing recommendations for appropriate hardware
> > and software architectures to use for safety applications
>
> Difficult. Again, needs an assumption on a system --- let us postpone.
>
> > - Verification and Validation Report, describing the procedures,
> > methods, and criteria used to develop and test that Linux
> > distribution prior to its release, and the results of those tests
>
> "Easy"(TM, final last words...) --- let us try to present you something here.
>
> > - Release Notes, describing any known issues or bugs in that
> > particular Linux distribution
>
> "Easy"(TM, final last words...) --- let us try to present you something here.
>
> Would you see some priority on the easy-marked ones and would you
> accept to postpone the two difficult ones?
>

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,

Lukas

> Then, I could present some "examples" for the easy results, and see
> where we go from there.
>
> Lukas
>
>
> >
> > Jason
> >
> > -----Original Message-----
> > From: Lukas Bulwahn <lukas.bulwahn@...>
> > Sent: Wednesday, February 16, 2022 7:38 AM
> > To: Smith, Jason <Jason.Smith@...>
> > Cc: elana.copperman@...; Shuah Khan
> > <skhan@...>; devel@...
> > Subject: Re: [ELISA Technical Community] TSC Meeting Agenda -
> > February 16 2022
> >
> > On Thu, Feb 10, 2022 at 4:29 AM Smith, Jason via lists.elisa.tech <jason.smith=ul.com@...> wrote:
> > >
> > > My goals are quick wins.  There are safety applications using Linux that either don't need safety certification or whose standards allow Linux to be treated as-is, i.e. software of unknown pedigree.  Just small improvements to Linux or relatively small additional pieces of information provided with Linux could offer a lot of value to these developers, allowing them to build safer products.  Examples: code improvements, new modules that add or support software safety measures, white papers, manuals, design guides, fault analyses, reports (verification, validation, review, etc.), release notes including known issues, etc.  In a way, this is perhaps a scaled-down version of Elana's (3).
> > >
> >
> > 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 prioritized list?
> >
> > Then, we could start at the top of that list and present an example of such pieces of information and discuss them with you to determine the potential effort of providing such information regularly (e.g., for every version) and completely (not just as some incomplete example for the purpose of having a discussion).
> >
> > I would like to contribute to creating that you see as quick wins. For me, there is nothing to lose here.
> >
> >
> > Lukas
> >
> > >
> > >
> > > That being said... I don't know if this is exactly what the community needs.
> > >
> > >
> > >
> > > I think (if we haven't done so already) we should go out far and wide across not only ELISA but Linux developers in general to find out what they really need.
> > >
> > >
> > >
> > > Are there enough developers of safety applications using Linux that are okay with treating Linux as-is, making it worthwhile to pursue my stated goal?
> > >
> > >
> > >
> > > Or are most folks trying to develop systems for self-driving cars using Linux and ultimately need compliance with ISO 26262?
> > >
> > >
> > >
> > > If the latter is true, start with Elana's (1).  It's going to be a lot of work.
> > >
> > >
> > >
> > > Jason
> > >
> > >
> > >
> > > From: devel@... <devel@...> On Behalf Of
> > > elana.copperman via lists.elisa.tech
> > > Sent: Wednesday, February 09, 2022 9:37 AM
> > > To: Shuah Khan <skhan@...>; devel@...
> > > Subject: Re: [ELISA Technical Community] TSC Meeting Agenda -
> > > February
> > > 16 2022
> > >
> > >
> > >
> > > Thanks, Shuah.  Some goals/ideas from my side:
> > >
> > > To establish a framework for communication and collaboration between Linux kernel developers/maintainers, safety experts and designers/developers of Linux based safety critical systems.  Without broader representation and communication, the work products of ELISA cannot have a context for deployment and acceptance.
> > > ELISA is a project of the Linux Foundation.  To leverage this umbrella, learn from its strong points, and help to improve the weaker points towards the long-term goal of integrating Linux successfully in safety critical systems.
> > > Work products (actual kernel patches) which will support the original ELISA mission statement:   to define and maintain a common set of elements, processes and tools that can be incorporated into Linux-based, safety-critical systems amenable to safety certification.
> > >
> > > Regards
> > >
> > > Elana
> > >
> > > ________________________________
> > >
> > > From: devel@... <devel@...> on behalf of
> > > Shuah Khan <skhan@...>
> > > Sent: Wednesday, February 9, 2022 5:20 PM
> > > To: devel@... <devel@...>
> > > Cc: Shuah Khan <skhan@...>
> > > Subject: [ELISA Technical Community] TSC Meeting Agenda - February
> > > 16
> > > 2022
> > >
> > >
> > >
> > > EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.
> > >
> > > All,
> > >
> > > Let's meet next week to discuss alignment on goals and what
> > > success looks like. Please respond to this thread to add you 1 or
> > > 2 items you consider important to achieve ELISA goals and make the
> > > project successful.
> > >
> > > I will compile the items and share the consolidated list before
> > > the meeting.
> > >
> > > thanks,
> > > -- Shuah
> > >
> > >
> > >
> > >
> > >
> > >
> > > This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
> > >
> > >
> >
> > This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
>
>
>
>
>

This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.


elana.copperman@...
 

Hi all,
A point to consider when choosing tasks:  perhaps we should define clear criteria, based on potential benefit to the community - and include that message in the introduction or overview.  Then try to focus on those tasks with highest potential benefit.
I am finding it difficult even to understand the intent or purpose of some of these documents.
Elana


From: Smith, Jason <Jason.Smith@...>
Sent: Wednesday, February 16, 2022 6:17 PM
To: Lukas Bulwahn <lukas.bulwahn@...>
Cc: Elana Copperman <Elana.Copperman@...>; Shuah Khan <skhan@...>; devel@... <devel@...>
Subject: RE: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022
 
EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

Hi Lukas,

Thanks for your reply.

I missed the very end of today's meeting (apologies to all for having to drop off the call before it concluded) so I'm not sure if and how much this was discussed further, but even some of the items you identified below that are "difficult" may not be so much if the efforts are constrained to a specific feature of Linux or are meta/high-level in nature.

Specific to your most recent message, the one item that I think would be useful to those who are just looking to create a safer system using Linux, or are looking to use Linux in the context of a system that requires conformance with a safety standard that allows treating Software of Unknown Pedigree (SOUP) as-is, would be release notes that document what are the known issues with Linux - whether they be of the nature of "don't do this; it's not a bug/defect, but if you implement something this way, you will get bad results" or actual, genuine software defects or bugs.

Unfortunately, I'm going to be off work during the next workshop in April and will not be able to present on any topics, so it'll be important for me to keep talking about these topics during our weekly meetings to keep momentum going.

Jason


-----Original Message-----
From: Lukas Bulwahn <lukas.bulwahn@...>
Sent: Wednesday, February 16, 2022 10:05 AM
To: Lukas Bulwahn <lukas.bulwahn@...>
Cc: Smith, Jason <Jason.Smith@...>; elana.copperman@...; Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

On Wed, Feb 16, 2022 at 3:13 PM Lukas Bulwahn via lists.elisa.tech <lukas.bulwahn=gmail.com@...> wrote:
>
> On Wed, Feb 16, 2022 at 2:49 PM Smith, Jason <Jason.Smith@...> wrote:
> >
> > A quick reply to Lukas prior to our meeting (I apologize, didn't have time to prioritize):
> >
> > We should revisit the work I/we started to do two years ago that never really materialized into anything, which is partially if not completely my own fault; conclusions from the third draft of the white paper I was working on:
> >
>
> Just a quick assessment:
>
> > - Manual, including general information pertaining to the Linux distribution like the version/revision and descriptions of APIs, etc.
>
> "Easy"(TM, final last words...) --- let us try to present you something here.
>
> > - Fault Analysis, identifying general risks associated with the use
> > of Linux and how those risks have been (or should be) addressed
>
> Difficult. What is a general risk? What is the system? Who needs to
> address? (I do not know what to do...) --- let us postpone.
>
> > - Design Guide, providing recommendations for appropriate hardware
> > and software architectures to use for safety applications
>
> Difficult. Again, needs an assumption on a system --- let us postpone.
>
> > - Verification and Validation Report, describing the procedures,
> > methods, and criteria used to develop and test that Linux
> > distribution prior to its release, and the results of those tests
>
> "Easy"(TM, final last words...) --- let us try to present you something here.
>
> > - Release Notes, describing any known issues or bugs in that
> > particular Linux distribution
>
> "Easy"(TM, final last words...) --- let us try to present you something here.
>
> Would you see some priority on the easy-marked ones and would you
> accept to postpone the two difficult ones?
>

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,

Lukas

> Then, I could present some "examples" for the easy results, and see
> where we go from there.
>
> Lukas
>
>
> >
> > Jason
> >
> > -----Original Message-----
> > From: Lukas Bulwahn <lukas.bulwahn@...>
> > Sent: Wednesday, February 16, 2022 7:38 AM
> > To: Smith, Jason <Jason.Smith@...>
> > Cc: elana.copperman@...; Shuah Khan
> > <skhan@...>; devel@...
> > Subject: Re: [ELISA Technical Community] TSC Meeting Agenda -
> > February 16 2022
> >
> > On Thu, Feb 10, 2022 at 4:29 AM Smith, Jason via lists.elisa.tech <jason.smith=ul.com@...> wrote:
> > >
> > > My goals are quick wins.  There are safety applications using Linux that either don't need safety certification or whose standards allow Linux to be treated as-is, i.e. software of unknown pedigree.  Just small improvements to Linux or relatively small additional pieces of information provided with Linux could offer a lot of value to these developers, allowing them to build safer products.  Examples: code improvements, new modules that add or support software safety measures, white papers, manuals, design guides, fault analyses, reports (verification, validation, review, etc.), release notes including known issues, etc.  In a way, this is perhaps a scaled-down version of Elana's (3).
> > >
> >
> > 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 prioritized list?
> >
> > Then, we could start at the top of that list and present an example of such pieces of information and discuss them with you to determine the potential effort of providing such information regularly (e.g., for every version) and completely (not just as some incomplete example for the purpose of having a discussion).
> >
> > I would like to contribute to creating that you see as quick wins. For me, there is nothing to lose here.
> >
> >
> > Lukas
> >
> > >
> > >
> > > That being said... I don't know if this is exactly what the community needs.
> > >
> > >
> > >
> > > I think (if we haven't done so already) we should go out far and wide across not only ELISA but Linux developers in general to find out what they really need.
> > >
> > >
> > >
> > > Are there enough developers of safety applications using Linux that are okay with treating Linux as-is, making it worthwhile to pursue my stated goal?
> > >
> > >
> > >
> > > Or are most folks trying to develop systems for self-driving cars using Linux and ultimately need compliance with ISO 26262?
> > >
> > >
> > >
> > > If the latter is true, start with Elana's (1).  It's going to be a lot of work.
> > >
> > >
> > >
> > > Jason
> > >
> > >
> > >
> > > From: devel@... <devel@...> On Behalf Of
> > > elana.copperman via lists.elisa.tech
> > > Sent: Wednesday, February 09, 2022 9:37 AM
> > > To: Shuah Khan <skhan@...>; devel@...
> > > Subject: Re: [ELISA Technical Community] TSC Meeting Agenda -
> > > February
> > > 16 2022
> > >
> > >
> > >
> > > Thanks, Shuah.  Some goals/ideas from my side:
> > >
> > > To establish a framework for communication and collaboration between Linux kernel developers/maintainers, safety experts and designers/developers of Linux based safety critical systems.  Without broader representation and communication, the work products of ELISA cannot have a context for deployment and acceptance.
> > > ELISA is a project of the Linux Foundation.  To leverage this umbrella, learn from its strong points, and help to improve the weaker points towards the long-term goal of integrating Linux successfully in safety critical systems.
> > > Work products (actual kernel patches) which will support the original ELISA mission statement:   to define and maintain a common set of elements, processes and tools that can be incorporated into Linux-based, safety-critical systems amenable to safety certification.
> > >
> > > Regards
> > >
> > > Elana
> > >
> > > ________________________________
> > >
> > > From: devel@... <devel@...> on behalf of
> > > Shuah Khan <skhan@...>
> > > Sent: Wednesday, February 9, 2022 5:20 PM
> > > To: devel@... <devel@...>
> > > Cc: Shuah Khan <skhan@...>
> > > Subject: [ELISA Technical Community] TSC Meeting Agenda - February
> > > 16
> > > 2022
> > >
> > >
> > >
> > > EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.
> > >
> > > All,
> > >
> > > Let's meet next week to discuss alignment on goals and what
> > > success looks like. Please respond to this thread to add you 1 or
> > > 2 items you consider important to achieve ELISA goals and make the
> > > project successful.
> > >
> > > I will compile the items and share the consolidated list before
> > > the meeting.
> > >
> > > thanks,
> > > -- Shuah
> > >
> > >
> > >
> > >
> > >
> > >
> > > This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
> > >
> > >
> >
> > This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
>
>
>
>
>

This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.


Smith, Jason
 

Hi Lukas,

Thanks for your reply.

I missed the very end of today's meeting (apologies to all for having to drop off the call before it concluded) so I'm not sure if and how much this was discussed further, but even some of the items you identified below that are "difficult" may not be so much if the efforts are constrained to a specific feature of Linux or are meta/high-level in nature.

Specific to your most recent message, the one item that I think would be useful to those who are just looking to create a safer system using Linux, or are looking to use Linux in the context of a system that requires conformance with a safety standard that allows treating Software of Unknown Pedigree (SOUP) as-is, would be release notes that document what are the known issues with Linux - whether they be of the nature of "don't do this; it's not a bug/defect, but if you implement something this way, you will get bad results" or actual, genuine software defects or bugs.

Unfortunately, I'm going to be off work during the next workshop in April and will not be able to present on any topics, so it'll be important for me to keep talking about these topics during our weekly meetings to keep momentum going.

Jason

-----Original Message-----
From: Lukas Bulwahn <lukas.bulwahn@...>
Sent: Wednesday, February 16, 2022 10:05 AM
To: Lukas Bulwahn <lukas.bulwahn@...>
Cc: Smith, Jason <Jason.Smith@...>; elana.copperman@...; Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

On Wed, Feb 16, 2022 at 3:13 PM Lukas Bulwahn via lists.elisa.tech <lukas.bulwahn=gmail.com@...> wrote:

On Wed, Feb 16, 2022 at 2:49 PM Smith, Jason <Jason.Smith@...> wrote:

A quick reply to Lukas prior to our meeting (I apologize, didn't have time to prioritize):

We should revisit the work I/we started to do two years ago that never really materialized into anything, which is partially if not completely my own fault; conclusions from the third draft of the white paper I was working on:
Just a quick assessment:

- Manual, including general information pertaining to the Linux distribution like the version/revision and descriptions of APIs, etc.
"Easy"(TM, final last words...) --- let us try to present you something here.

- Fault Analysis, identifying general risks associated with the use
of Linux and how those risks have been (or should be) addressed
Difficult. What is a general risk? What is the system? Who needs to
address? (I do not know what to do...) --- let us postpone.

- Design Guide, providing recommendations for appropriate hardware
and software architectures to use for safety applications
Difficult. Again, needs an assumption on a system --- let us postpone.

- Verification and Validation Report, describing the procedures,
methods, and criteria used to develop and test that Linux
distribution prior to its release, and the results of those tests
"Easy"(TM, final last words...) --- let us try to present you something here.

- Release Notes, describing any known issues or bugs in that
particular Linux distribution
"Easy"(TM, final last words...) --- let us try to present you something here.

Would you see some priority on the easy-marked ones and would you
accept to postpone the two difficult ones?
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,

Lukas

Then, I could present some "examples" for the easy results, and see
where we go from there.

Lukas



Jason

-----Original Message-----
From: Lukas Bulwahn <lukas.bulwahn@...>
Sent: Wednesday, February 16, 2022 7:38 AM
To: Smith, Jason <Jason.Smith@...>
Cc: elana.copperman@...; Shuah Khan
<skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda -
February 16 2022

On Thu, Feb 10, 2022 at 4:29 AM Smith, Jason via lists.elisa.tech <jason.smith=ul.com@...> wrote:

My goals are quick wins. There are safety applications using Linux that either don't need safety certification or whose standards allow Linux to be treated as-is, i.e. software of unknown pedigree. Just small improvements to Linux or relatively small additional pieces of information provided with Linux could offer a lot of value to these developers, allowing them to build safer products. Examples: code improvements, new modules that add or support software safety measures, white papers, manuals, design guides, fault analyses, reports (verification, validation, review, etc.), release notes including known issues, etc. In a way, this is perhaps a scaled-down version of Elana's (3).
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 prioritized list?

Then, we could start at the top of that list and present an example of such pieces of information and discuss them with you to determine the potential effort of providing such information regularly (e.g., for every version) and completely (not just as some incomplete example for the purpose of having a discussion).

I would like to contribute to creating that you see as quick wins. For me, there is nothing to lose here.


Lukas



That being said... I don't know if this is exactly what the community needs.



I think (if we haven't done so already) we should go out far and wide across not only ELISA but Linux developers in general to find out what they really need.



Are there enough developers of safety applications using Linux that are okay with treating Linux as-is, making it worthwhile to pursue my stated goal?



Or are most folks trying to develop systems for self-driving cars using Linux and ultimately need compliance with ISO 26262?



If the latter is true, start with Elana's (1). It's going to be a lot of work.



Jason



From: devel@... <devel@...> On Behalf Of
elana.copperman via lists.elisa.tech
Sent: Wednesday, February 09, 2022 9:37 AM
To: Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda -
February
16 2022



Thanks, Shuah. Some goals/ideas from my side:

To establish a framework for communication and collaboration between Linux kernel developers/maintainers, safety experts and designers/developers of Linux based safety critical systems. Without broader representation and communication, the work products of ELISA cannot have a context for deployment and acceptance.
ELISA is a project of the Linux Foundation. To leverage this umbrella, learn from its strong points, and help to improve the weaker points towards the long-term goal of integrating Linux successfully in safety critical systems.
Work products (actual kernel patches) which will support the original ELISA mission statement: to define and maintain a common set of elements, processes and tools that can be incorporated into Linux-based, safety-critical systems amenable to safety certification.

Regards

Elana

________________________________

From: devel@... <devel@...> on behalf of
Shuah Khan <skhan@...>
Sent: Wednesday, February 9, 2022 5:20 PM
To: devel@... <devel@...>
Cc: Shuah Khan <skhan@...>
Subject: [ELISA Technical Community] TSC Meeting Agenda - February
16
2022



EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

All,

Let's meet next week to discuss alignment on goals and what
success looks like. Please respond to this thread to add you 1 or
2 items you consider important to achieve ELISA goals and make the
project successful.

I will compile the items and share the consolidated list before
the meeting.

thanks,
-- Shuah






This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.

This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.



This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.


Lukas Bulwahn
 

On Wed, Feb 16, 2022 at 3:13 PM Lukas Bulwahn via lists.elisa.tech
<lukas.bulwahn=gmail.com@...> wrote:

On Wed, Feb 16, 2022 at 2:49 PM Smith, Jason <Jason.Smith@...> wrote:

A quick reply to Lukas prior to our meeting (I apologize, didn't have time to prioritize):

We should revisit the work I/we started to do two years ago that never really materialized into anything, which is partially if not completely my own fault; conclusions from the third draft of the white paper I was working on:
Just a quick assessment:

- Manual, including general information pertaining to the Linux distribution like the version/revision and descriptions of APIs, etc.
"Easy"(TM, final last words...) --- let us try to present you something here.

- Fault Analysis, identifying general risks associated with the use of Linux and how those risks have been (or should be) addressed
Difficult. What is a general risk? What is the system? Who needs to
address? (I do not know what to do...) --- let us postpone.

- Design Guide, providing recommendations for appropriate hardware and software architectures to use for safety applications
Difficult. Again, needs an assumption on a system --- let us postpone.

- Verification and Validation Report, describing the procedures, methods, and criteria used to develop and test that Linux distribution prior to its release, and the results of those tests
"Easy"(TM, final last words...) --- let us try to present you something here.

- Release Notes, describing any known issues or bugs in that particular Linux distribution
"Easy"(TM, final last words...) --- let us try to present you something here.

Would you see some priority on the easy-marked ones and would you
accept to postpone the two difficult ones?
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,

Lukas

Then, I could present some "examples" for the easy results, and see
where we go from there.

Lukas



Jason

-----Original Message-----
From: Lukas Bulwahn <lukas.bulwahn@...>
Sent: Wednesday, February 16, 2022 7:38 AM
To: Smith, Jason <Jason.Smith@...>
Cc: elana.copperman@...; Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

On Thu, Feb 10, 2022 at 4:29 AM Smith, Jason via lists.elisa.tech <jason.smith=ul.com@...> wrote:

My goals are quick wins. There are safety applications using Linux that either don’t need safety certification or whose standards allow Linux to be treated as-is, i.e. software of unknown pedigree. Just small improvements to Linux or relatively small additional pieces of information provided with Linux could offer a lot of value to these developers, allowing them to build safer products. Examples: code improvements, new modules that add or support software safety measures, white papers, manuals, design guides, fault analyses, reports (verification, validation, review, etc.), release notes including known issues, etc. In a way, this is perhaps a scaled-down version of Elana’s (3).
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 prioritized list?

Then, we could start at the top of that list and present an example of such pieces of information and discuss them with you to determine the potential effort of providing such information regularly (e.g., for every version) and completely (not just as some incomplete example for the purpose of having a discussion).

I would like to contribute to creating that you see as quick wins. For me, there is nothing to lose here.


Lukas



That being said… I don’t know if this is exactly what the community needs.



I think (if we haven’t done so already) we should go out far and wide across not only ELISA but Linux developers in general to find out what they really need.



Are there enough developers of safety applications using Linux that are okay with treating Linux as-is, making it worthwhile to pursue my stated goal?



Or are most folks trying to develop systems for self-driving cars using Linux and ultimately need compliance with ISO 26262?



If the latter is true, start with Elana’s (1). It’s going to be a lot of work.



Jason



From: devel@... <devel@...> On Behalf Of
elana.copperman via lists.elisa.tech
Sent: Wednesday, February 09, 2022 9:37 AM
To: Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February
16 2022



Thanks, Shuah. Some goals/ideas from my side:

To establish a framework for communication and collaboration between Linux kernel developers/maintainers, safety experts and designers/developers of Linux based safety critical systems. Without broader representation and communication, the work products of ELISA cannot have a context for deployment and acceptance.
ELISA is a project of the Linux Foundation. To leverage this umbrella, learn from its strong points, and help to improve the weaker points towards the long-term goal of integrating Linux successfully in safety critical systems.
Work products (actual kernel patches) which will support the original ELISA mission statement: to define and maintain a common set of elements, processes and tools that can be incorporated into Linux-based, safety-critical systems amenable to safety certification.

Regards

Elana

________________________________

From: devel@... <devel@...> on behalf of
Shuah Khan <skhan@...>
Sent: Wednesday, February 9, 2022 5:20 PM
To: devel@... <devel@...>
Cc: Shuah Khan <skhan@...>
Subject: [ELISA Technical Community] TSC Meeting Agenda - February 16
2022



EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

All,

Let's meet next week to discuss alignment on goals and what success
looks like. Please respond to this thread to add you 1 or 2 items you
consider important to achieve ELISA goals and make the project
successful.

I will compile the items and share the consolidated list before the
meeting.

thanks,
-- Shuah






This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.

This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.




Lukas Bulwahn
 

On Wed, Feb 16, 2022 at 2:49 PM Smith, Jason <Jason.Smith@...> wrote:

A quick reply to Lukas prior to our meeting (I apologize, didn't have time to prioritize):

We should revisit the work I/we started to do two years ago that never really materialized into anything, which is partially if not completely my own fault; conclusions from the third draft of the white paper I was working on:
Just a quick assessment:

- Manual, including general information pertaining to the Linux distribution like the version/revision and descriptions of APIs, etc.
"Easy"(TM, final last words...) --- let us try to present you something here.

- Fault Analysis, identifying general risks associated with the use of Linux and how those risks have been (or should be) addressed
Difficult. What is a general risk? What is the system? Who needs to
address? (I do not know what to do...) --- let us postpone.

- Design Guide, providing recommendations for appropriate hardware and software architectures to use for safety applications
Difficult. Again, needs an assumption on a system --- let us postpone.

- Verification and Validation Report, describing the procedures, methods, and criteria used to develop and test that Linux distribution prior to its release, and the results of those tests
"Easy"(TM, final last words...) --- let us try to present you something here.

- Release Notes, describing any known issues or bugs in that particular Linux distribution
"Easy"(TM, final last words...) --- let us try to present you something here.

Would you see some priority on the easy-marked ones and would you
accept to postpone the two difficult ones?

Then, I could present some "examples" for the easy results, and see
where we go from there.

Lukas



Jason

-----Original Message-----
From: Lukas Bulwahn <lukas.bulwahn@...>
Sent: Wednesday, February 16, 2022 7:38 AM
To: Smith, Jason <Jason.Smith@...>
Cc: elana.copperman@...; Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

On Thu, Feb 10, 2022 at 4:29 AM Smith, Jason via lists.elisa.tech <jason.smith=ul.com@...> wrote:

My goals are quick wins. There are safety applications using Linux that either don’t need safety certification or whose standards allow Linux to be treated as-is, i.e. software of unknown pedigree. Just small improvements to Linux or relatively small additional pieces of information provided with Linux could offer a lot of value to these developers, allowing them to build safer products. Examples: code improvements, new modules that add or support software safety measures, white papers, manuals, design guides, fault analyses, reports (verification, validation, review, etc.), release notes including known issues, etc. In a way, this is perhaps a scaled-down version of Elana’s (3).
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 prioritized list?

Then, we could start at the top of that list and present an example of such pieces of information and discuss them with you to determine the potential effort of providing such information regularly (e.g., for every version) and completely (not just as some incomplete example for the purpose of having a discussion).

I would like to contribute to creating that you see as quick wins. For me, there is nothing to lose here.


Lukas



That being said… I don’t know if this is exactly what the community needs.



I think (if we haven’t done so already) we should go out far and wide across not only ELISA but Linux developers in general to find out what they really need.



Are there enough developers of safety applications using Linux that are okay with treating Linux as-is, making it worthwhile to pursue my stated goal?



Or are most folks trying to develop systems for self-driving cars using Linux and ultimately need compliance with ISO 26262?



If the latter is true, start with Elana’s (1). It’s going to be a lot of work.



Jason



From: devel@... <devel@...> On Behalf Of
elana.copperman via lists.elisa.tech
Sent: Wednesday, February 09, 2022 9:37 AM
To: Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February
16 2022



Thanks, Shuah. Some goals/ideas from my side:

To establish a framework for communication and collaboration between Linux kernel developers/maintainers, safety experts and designers/developers of Linux based safety critical systems. Without broader representation and communication, the work products of ELISA cannot have a context for deployment and acceptance.
ELISA is a project of the Linux Foundation. To leverage this umbrella, learn from its strong points, and help to improve the weaker points towards the long-term goal of integrating Linux successfully in safety critical systems.
Work products (actual kernel patches) which will support the original ELISA mission statement: to define and maintain a common set of elements, processes and tools that can be incorporated into Linux-based, safety-critical systems amenable to safety certification.

Regards

Elana

________________________________

From: devel@... <devel@...> on behalf of
Shuah Khan <skhan@...>
Sent: Wednesday, February 9, 2022 5:20 PM
To: devel@... <devel@...>
Cc: Shuah Khan <skhan@...>
Subject: [ELISA Technical Community] TSC Meeting Agenda - February 16
2022



EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

All,

Let's meet next week to discuss alignment on goals and what success
looks like. Please respond to this thread to add you 1 or 2 items you
consider important to achieve ELISA goals and make the project
successful.

I will compile the items and share the consolidated list before the
meeting.

thanks,
-- Shuah






This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.

This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.


Smith, Jason
 

A quick reply to Lukas prior to our meeting (I apologize, didn't have time to prioritize):

We should revisit the work I/we started to do two years ago that never really materialized into anything, which is partially if not completely my own fault; conclusions from the third draft of the white paper I was working on:

- Manual, including general information pertaining to the Linux distribution like the version/revision and descriptions of APIs, etc.
- Fault Analysis, identifying general risks associated with the use of Linux and how those risks have been (or should be) addressed
- Design Guide, providing recommendations for appropriate hardware and software architectures to use for safety applications
- Verification and Validation Report, describing the procedures, methods, and criteria used to develop and test that Linux distribution prior to its release, and the results of those tests
- Release Notes, describing any known issues or bugs in that particular Linux distribution

Jason

-----Original Message-----
From: Lukas Bulwahn <lukas.bulwahn@...>
Sent: Wednesday, February 16, 2022 7:38 AM
To: Smith, Jason <Jason.Smith@...>
Cc: elana.copperman@...; Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

On Thu, Feb 10, 2022 at 4:29 AM Smith, Jason via lists.elisa.tech <jason.smith=ul.com@...> wrote:

My goals are quick wins. There are safety applications using Linux that either don’t need safety certification or whose standards allow Linux to be treated as-is, i.e. software of unknown pedigree. Just small improvements to Linux or relatively small additional pieces of information provided with Linux could offer a lot of value to these developers, allowing them to build safer products. Examples: code improvements, new modules that add or support software safety measures, white papers, manuals, design guides, fault analyses, reports (verification, validation, review, etc.), release notes including known issues, etc. In a way, this is perhaps a scaled-down version of Elana’s (3).
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 prioritized list?

Then, we could start at the top of that list and present an example of such pieces of information and discuss them with you to determine the potential effort of providing such information regularly (e.g., for every version) and completely (not just as some incomplete example for the purpose of having a discussion).

I would like to contribute to creating that you see as quick wins. For me, there is nothing to lose here.


Lukas



That being said… I don’t know if this is exactly what the community needs.



I think (if we haven’t done so already) we should go out far and wide across not only ELISA but Linux developers in general to find out what they really need.



Are there enough developers of safety applications using Linux that are okay with treating Linux as-is, making it worthwhile to pursue my stated goal?



Or are most folks trying to develop systems for self-driving cars using Linux and ultimately need compliance with ISO 26262?



If the latter is true, start with Elana’s (1). It’s going to be a lot of work.



Jason



From: devel@... <devel@...> On Behalf Of
elana.copperman via lists.elisa.tech
Sent: Wednesday, February 09, 2022 9:37 AM
To: Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February
16 2022



Thanks, Shuah. Some goals/ideas from my side:

To establish a framework for communication and collaboration between Linux kernel developers/maintainers, safety experts and designers/developers of Linux based safety critical systems. Without broader representation and communication, the work products of ELISA cannot have a context for deployment and acceptance.
ELISA is a project of the Linux Foundation. To leverage this umbrella, learn from its strong points, and help to improve the weaker points towards the long-term goal of integrating Linux successfully in safety critical systems.
Work products (actual kernel patches) which will support the original ELISA mission statement: to define and maintain a common set of elements, processes and tools that can be incorporated into Linux-based, safety-critical systems amenable to safety certification.

Regards

Elana

________________________________

From: devel@... <devel@...> on behalf of
Shuah Khan <skhan@...>
Sent: Wednesday, February 9, 2022 5:20 PM
To: devel@... <devel@...>
Cc: Shuah Khan <skhan@...>
Subject: [ELISA Technical Community] TSC Meeting Agenda - February 16
2022



EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

All,

Let's meet next week to discuss alignment on goals and what success
looks like. Please respond to this thread to add you 1 or 2 items you
consider important to achieve ELISA goals and make the project
successful.

I will compile the items and share the consolidated list before the
meeting.

thanks,
-- Shuah






This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.

This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.


Lukas Bulwahn
 

On Thu, Feb 10, 2022 at 4:29 AM Smith, Jason via lists.elisa.tech
<jason.smith=ul.com@...> wrote:

My goals are quick wins. There are safety applications using Linux that either don’t need safety certification or whose standards allow Linux to be treated as-is, i.e. software of unknown pedigree. Just small improvements to Linux or relatively small additional pieces of information provided with Linux could offer a lot of value to these developers, allowing them to build safer products. Examples: code improvements, new modules that add or support software safety measures, white papers, manuals, design guides, fault analyses, reports (verification, validation, review, etc.), release notes including known issues, etc. In a way, this is perhaps a scaled-down version of Elana’s (3).
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 prioritized list?

Then, we could start at the top of that list and present an example of
such pieces of information and discuss them with you to determine the
potential effort of providing such information regularly (e.g., for
every version) and completely (not just as some incomplete example for
the purpose of having a discussion).

I would like to contribute to creating that you see as quick wins. For
me, there is nothing to lose here.


Lukas



That being said… I don’t know if this is exactly what the community needs.



I think (if we haven’t done so already) we should go out far and wide across not only ELISA but Linux developers in general to find out what they really need.



Are there enough developers of safety applications using Linux that are okay with treating Linux as-is, making it worthwhile to pursue my stated goal?



Or are most folks trying to develop systems for self-driving cars using Linux and ultimately need compliance with ISO 26262?



If the latter is true, start with Elana’s (1). It’s going to be a lot of work.



Jason



From: devel@... <devel@...> On Behalf Of elana.copperman via lists.elisa.tech
Sent: Wednesday, February 09, 2022 9:37 AM
To: Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022



Thanks, Shuah. Some goals/ideas from my side:

To establish a framework for communication and collaboration between Linux kernel developers/maintainers, safety experts and designers/developers of Linux based safety critical systems. Without broader representation and communication, the work products of ELISA cannot have a context for deployment and acceptance.
ELISA is a project of the Linux Foundation. To leverage this umbrella, learn from its strong points, and help to improve the weaker points towards the long-term goal of integrating Linux successfully in safety critical systems.
Work products (actual kernel patches) which will support the original ELISA mission statement: to define and maintain a common set of elements, processes and tools that can be incorporated into Linux-based, safety-critical systems amenable to safety certification.

Regards

Elana

________________________________

From: devel@... <devel@...> on behalf of Shuah Khan <skhan@...>
Sent: Wednesday, February 9, 2022 5:20 PM
To: devel@... <devel@...>
Cc: Shuah Khan <skhan@...>
Subject: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022



EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

All,

Let's meet next week to discuss alignment on goals and what success
looks like. Please respond to this thread to add you 1 or 2 items
you consider important to achieve ELISA goals and make the project
successful.

I will compile the items and share the consolidated list before the
meeting.

thanks,
-- Shuah






This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.


Lukas Bulwahn
 

On Wed, Feb 9, 2022 at 4:37 PM <elana.copperman@...> wrote:

Thanks, Shuah. Some goals/ideas from my side:

To establish a framework for communication and collaboration between Linux kernel developers/maintainers, safety experts and designers/developers of Linux based safety critical systems. Without broader representation and communication, the work products of ELISA cannot have a context for deployment and acceptance.
ELISA is a project of the Linux Foundation. To leverage this umbrella, learn from its strong points, and help to improve the weaker points towards the long-term goal of integrating Linux successfully in safety critical systems.
Work products (actual kernel patches) which will support the original ELISA mission statement: to define and maintain a common set of elements, processes and tools that can be incorporated into Linux-based, safety-critical systems amenable to safety certification.
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,, not even more than
a single author... depending what you 'count' as publication).

- I could not understand how the work and ELISA community contributes
or simplifies my (potential and my team's potential) contributions
(e.g., patches) to the Linux kernel. To my understanding, as of now, I
am in a better position to simply ignore the ELISA Project and just
work with the kernel community towards my specific goals. In other
words, ELISA project members have no positive nor negative impact on
my and my team's potential kernel contributions.

This raises the question:

What changes need to happen in our work mode to not continue in the
mode that we ended up in after the first three years of this project?

Just some food for thought,

Lukas


Regards
Elana
________________________________
From: devel@... <devel@...> on behalf of Shuah Khan <skhan@...>
Sent: Wednesday, February 9, 2022 5:20 PM
To: devel@... <devel@...>
Cc: Shuah Khan <skhan@...>
Subject: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

All,

Let's meet next week to discuss alignment on goals and what success
looks like. Please respond to this thread to add you 1 or 2 items
you consider important to achieve ELISA goals and make the project
successful.

I will compile the items and share the consolidated list before the
meeting.

thanks,
-- Shuah







Gabriele Paoloni
 

Hi All

On my side I am fully supportive of Elana's goals and, WRT to these goals. I think that what Paul
pointed out in the email below is the basis to achieve such goals.

Thanks
Gab 


On Tue, Feb 15, 2022 at 4:36 PM Paul Albertella <paul.albertella@...> wrote:
Hi,

I support many of the previous suggestions, but would like to add the
following goals:

1) Document the working assumptions (and provisional conclusions) that
underpin ELISA discussions, to provide context for new contributors -
and confirm what we actually have consensus about!

2) Establish a 'contribution' process for material that is intended to
form part of ELISA deliverables, including contribution and review
criteria (e.g. must be able to identify the contributor and what they
contributed, must be peer-reviewed).

3) Establish a 'publication' process for making ELISA deliverables
(including formal draft or acknowledged incomplete versions) available
to a wider audience, including review and approval criteria


I've previously proposed that we could best accomplish 2 and 3 by using
ELISA's GitHub repos to manage storage, updates, review and publication
(i.e. merge into a protected main branch) in a consistent way. Jochen
already has a Contribution Workflow [1] for the Automotive WG that we
could use as a starting point. We could extend this to make it more
accessible for those unfamiliar with GitHub.

I think it's important to establish and use this kind of process as a
matter of course, even if we collaborate on drafting input material
elsewhere, because it is all too easy to lose track of documents on
Google Drive, and newcomers have almost no hope of finding them.

To make published material in a GitHub repo more accessible, we have
talked before (and John MacGregor shared a PoC) about using GitHub Pages
to generate web-based documentation and/or PDFs.

regards,

Paul

[1]
https://github.com/elisa-tech/wg-automotive/blob/master/README.md#contribution-workflow


On 15/02/2022 07:30, Philipp Ahmann wrote:
> Hello Shuah, all,
>
> although, I have a customer meeting during the first half of the TSC and
> can onlyjoin later,I would like to contribute my goal/success ideasg for
> the year. I believe they also fit to what has been contributed so far.
>
> We have different puzzle pieces within ELISA which we call "work
> groups". This was well visualized in more than one workshop. Even trials
> have been made how these work groups should interact. However, I fear
> that the binding of work groups is still very weak. Use case work groups
> should contribute to the other work groups and provide input and vise
> versa. We set goals and give regular reports in TSC meetings where we
> are within the work group, but we should also report and focus what we
> have done to serve the other work groups. Which impact does our work
> make to the other work groups? If we cannot show how how the different
> groups interact (on engineering not powerpoint level), we will never be
> able to provide a complete picture. Because one thing is for sure in my
> perspective: We will need all the existing groups to enable Linux in
> safety applications.
>
> My proposal and therefore goal is: Make both, the medical and automotive
> work group use cases, ready to serve as a proper blue print for further
> use cases during this year. Show where the gaps are, but map existing
> work packages/artifacts from other groups and link to show how these
> gaps will be filled. The material generated should show how the work
> products of all work group interact with each other, and that medical
> devices and automotive are aligned in the way of documentation, so you
> can really call results a blueprint. We need to generate the big
> picture, make on-boarding easier and generate transparency where support
> is needed by enabling direct "picking up of tasks" from a roadmap and
> current cycle.
>
> We should also try to reach out to further contributors to get member
> commitment, but for this we need to have proper material and demands
> declared.
>
> Best regards,
>
> Philipp
>
> ---
>
>
> Am Mo., 14. Feb. 2022 um 17:24 Uhr schrieb Walt Miner
> <wminer@... <mailto:wminer@...>>:
>
>     I think I am aligned with Elena's goals.  We have been working
>     towards Goal 1 in the Automotive WG, but progress is slow,
>     especially given the fact that a number of participants have dropped
>     out or will be dropping out shortly. I will work with the AGL
>     community to try to push for more involvement from that community
>     (aligns with Goal 2) and we have a use case (Instrument Cluster
>     tell-tale)  that is seemingly simple, but provides a rich set of
>     implementation details to work through and eventually get to Goal 3.
>
>       I will try to participate in this week's TSC meeting. Generally
>     AGL has a meeting scheduled at the same time that makes it
>     impossible for me to attend, but I feel that we are at an important
>     junction in the ELISA project so I will figure out how to attend the
>     next few TSC meetings.
>
>     Regards,
>     Walt
>
>
>     Walt Miner
>     AGL Community Manager
>     The Linux Foundation
>
>     Visit us at:
>     www.automotivegradelinux.org <http://www.automotivegradelinux.org>
>     lists.automotivelinux.org <http://lists.automotivelinux.org>
>     www.linuxfoundation.org <http://www.linuxfoundation.org>
>
>
>
>
>     On Thu, Feb 10, 2022 at 8:52 AM <elana.copperman@...
>     <mailto:elana.copperman@...>> wrote:
>
>         I stand corrected.  Perhaps more accurate:____
>
>         /Those who are "ok with Linux as is", /believe that they /don't
>         really need any by-products of ELISA.   They will continue to do
>         what they are already doing, /unless we communicate the benefits
>         and feasibility./.____/
>
>         __ __
>
>         __ __
>
>         *From:* Smith, Jason <Jason.Smith@...
>         <mailto:Jason.Smith@...>>
>         *Sent:* Thursday, February 10, 2022 3:49 PM
>         *To:* Elana Copperman <Elana.Copperman@...
>         <mailto:Elana.Copperman@...>>; Shuah Khan
>         <skhan@... <mailto:skhan@...>>;
>         devel@...
>         *Subject:* RE: [ELISA Technical Community] TSC Meeting Agenda -
>         February 16 2022____
>
>         __ __
>
>         *EXTERNAL EMAIL**:*Do not click any links or open any
>         attachments unless you trust the sender and know the content is
>         safe.____
>
>         Hi Elana,____
>
>         __ __
>
>         Just wanted to respond to one of your comments:____
>
>         __ __
>
>         /Those who are "ok with Linux as is", don't really need any
>         by-products of ELISA.   They will continue to do what they are
>         already doing.____/
>
>         __ __
>
>         I don’t believe this is entirely true.____
>
>         __ __
>
>         More clearly communicating potential shortcomings of Linux to
>         these folks will enable them to better design a system around
>         Linux to make that overall system safer.____
>
>         __ __
>
>         *Jason R. Smith, UL-CFSX
>         <https://www.ul.com/services/functional-safety-certification-and-training-program>*
>         Principal Engineer, Robots & Control Systems (CMIT)____
>
>         /Distinguished Member of Technical Staff____/
>
>         --------------------------------------------------
>         UL LLC
>         333 Pfingsten Road
>         Northbrook, IL 60062-2096 US
>         T: 1.847.664.1352
>         W: https://www.ul.com <https://www.ul.com>____
>
>         __ __
>
>         *From:* Elana Copperman <Elana.Copperman@...
>         <mailto:Elana.Copperman@...>>
>         *Sent:* Thursday, February 10, 2022 1:41 AM
>         *To:* Smith, Jason <Jason.Smith@...
>         <mailto:Jason.Smith@...>>; Shuah Khan
>         <skhan@... <mailto:skhan@...>>;
>         devel@... <mailto:devel@...>
>         *Subject:* RE: [ELISA Technical Community] TSC Meeting Agenda -
>         February 16 2022____
>
>         __ __
>
>         Thanks, Jason.  I think we are pretty much saying the same
>         thing, only (as usual in ELISA) from 2 different sides of the
>         coin.____
>
>         Those who are "ok with Linux as is", don't really need any
>         by-products of ELISA.   They will continue to do what they are
>         already doing.____
>
>         For those who need stricter compliance with the standards, it is
>         already clear that full compliance will not happen.  So that
>         some iterative process (similar to what Jason describes) will
>         bring Linux*closer* to what the safety standards expect, leaving
>         it up to the integrator to fill in any remaining gaps for
>         his/her use case.  I don't think ELISA can/should do more; but
>         even this will be a great contribution.____
>
>         __ __
>
>         My only real concern is that we need to bring in a broader
>         spectrum of contributors, so that we can expand our context for
>         deployment and acceptance.  As Jason says, "I don't know if this
>         is exactly what the community needs".  The community of Linux
>         users for safety critical applications is enormous, and we have
>         lost them (they attended the early workshops but have since
>         petered out).  We need to hear their voice.____
>
>         Any proposal, Jason's or mine or anyone else's, is an iterative
>         process.  But we need to be moving in a clear direction for what
>         the world needs.____
>
>         Regards____
>
>         Elana____
>
>         __ __
>
>         *From:* Smith, Jason <Jason.Smith@...
>         <mailto:Jason.Smith@...>>
>         *Sent:* Thursday, February 10, 2022 5:29 AM
>         *To:* Elana Copperman <Elana.Copperman@...
>         <mailto:Elana.Copperman@...>>; Shuah Khan
>         <skhan@... <mailto:skhan@...>>;
>         devel@... <mailto:devel@...>
>         *Subject:* RE: [ELISA Technical Community] TSC Meeting Agenda -
>         February 16 2022____
>
>         __ __
>
>         *EXTERNAL EMAIL**:*Do not click any links or open any
>         attachments unless you trust the sender and know the content is
>         safe.____
>
>         My goals are quick wins.  There are safety applications using
>         Linux that either don’t need safety certification or whose
>         standards allow Linux to be treated as-is, i.e. software of
>         unknown pedigree.  Just small improvements to Linux or
>         relatively small additional pieces of information provided with
>         Linux could offer a lot of value to these developers, allowing
>         them to build safer products.  Examples: code improvements, new
>         modules that add or support software safety measures, white
>         papers, manuals, design guides, fault analyses, reports
>         (verification, validation, review, etc.), release notes
>         including known issues, etc.  In a way, this is perhaps a
>         scaled-down version of Elana’s (3).____
>
>         __ __
>
>         That being said… I don’t know if this is exactly what the
>         community needs.____
>
>         __ __
>
>         I think (if we haven’t done so already) we should go out far and
>         wide across not only ELISA but Linux developers in general to
>         find out what they really need.____
>
>         __ __
>
>         Are there enough developers of safety applications using Linux
>         that are okay with treating Linux as-is, making it worthwhile to
>         pursue my stated goal?____
>
>         __ __
>
>         Or are most folks trying to develop systems for self-driving
>         cars using Linux and ultimately need compliance with ISO 26262?____
>
>         __ __
>
>         If the latter is true, start with Elana’s (1).  It’s going to be
>         a lot of work.____
>
>         __ __
>
>         Jason____
>
>         __ __
>
>         *From:* devel@... <mailto:devel@...>
>         <devel@... <mailto:devel@...>> *On
>         Behalf Of *elana.copperman via lists.elisa.tech
>         *Sent:* Wednesday, February 09, 2022 9:37 AM
>         *To:* Shuah Khan <skhan@...
>         <mailto:skhan@...>>; devel@...
>         <mailto:devel@...>
>         *Subject:* Re: [ELISA Technical Community] TSC Meeting Agenda -
>         February 16 2022____
>
>         __ __
>
>         Thanks, Shuah.  Some goals/ideas from my side:____
>
>          1. To establish a framework for communication and collaboration
>             between Linux kernel developers/maintainers, safety experts
>             and designers/developers of Linux based safety critical
>             systems.  Without broader representation and communication,
>             the work products of ELISA cannot have a context for
>             deployment and acceptance.____
>          2. ELISA is a project of the Linux Foundation.  To leverage
>             this umbrella, learn from its strong points, and help to
>             improve the weaker points towards the long-term goal of
>             integrating Linux successfully in safety critical systems.____
>          3. Work products (actual kernel patches) which will support the
>             original ELISA mission statement:   to define and maintain a
>             common set of elements, processes and tools that can be
>             incorporated into Linux-based, safety-critical systems
>             amenable to safety certification.____
>
>         Regards____
>
>         Elana____
>
>         ------------------------------------------------------------------------
>
>         *From:*devel@... <mailto:devel@...>
>         <devel@... <mailto:devel@...>> on
>         behalf of Shuah Khan <skhan@...
>         <mailto:skhan@...>>
>         *Sent:* Wednesday, February 9, 2022 5:20 PM
>         *To:* devel@... <mailto:devel@...>
>         <devel@... <mailto:devel@...>>
>         *Cc:* Shuah Khan <skhan@...
>         <mailto:skhan@...>>
>         *Subject:* [ELISA Technical Community] TSC Meeting Agenda -
>         February 16 2022 ____
>
>         ____
>
>         EXTERNAL EMAIL: Do not click any links or open any attachments
>         unless you trust the sender and know the content is safe.
>
>         All,
>
>         Let's meet next week to discuss alignment on goals and what success
>         looks like. Please respond to this thread to add you 1 or 2 items
>         you consider important to achieve ELISA goals and make the project
>         successful.
>
>         I will compile the items and share the consolidated list before the
>         meeting.
>
>         thanks,
>         -- Shuah
>
>
>         ____
>
>         __
>
>
>         This e-mail may contain privileged or confidential information.
>         If you are not the intended recipient: (1) you may not disclose,
>         use, distribute, copy or rely upon this message or
>         attachment(s); and (2) please notify the sender by reply e-mail,
>         and then delete this message and its attachment(s). Underwriters
>         Laboratories Inc. and its affiliates disclaim all liability for
>         any errors, omissions, corruption or virus in this message or
>         any attachments.____
>
>
>         This e-mail may contain privileged or confidential information.
>         If you are not the intended recipient: (1) you may not disclose,
>         use, distribute, copy or rely upon this message or
>         attachment(s); and (2) please notify the sender by reply e-mail,
>         and then delete this message and its attachment(s). Underwriters
>         Laboratories Inc. and its affiliates disclaim all liability for
>         any errors, omissions, corruption or virus in this message or
>         any attachments.____
>
>






Paul Albertella
 

Hi,

I support many of the previous suggestions, but would like to add the following goals:

1) Document the working assumptions (and provisional conclusions) that underpin ELISA discussions, to provide context for new contributors - and confirm what we actually have consensus about!

2) Establish a 'contribution' process for material that is intended to form part of ELISA deliverables, including contribution and review criteria (e.g. must be able to identify the contributor and what they contributed, must be peer-reviewed).

3) Establish a 'publication' process for making ELISA deliverables (including formal draft or acknowledged incomplete versions) available to a wider audience, including review and approval criteria


I've previously proposed that we could best accomplish 2 and 3 by using ELISA's GitHub repos to manage storage, updates, review and publication (i.e. merge into a protected main branch) in a consistent way. Jochen already has a Contribution Workflow [1] for the Automotive WG that we could use as a starting point. We could extend this to make it more accessible for those unfamiliar with GitHub.

I think it's important to establish and use this kind of process as a matter of course, even if we collaborate on drafting input material elsewhere, because it is all too easy to lose track of documents on Google Drive, and newcomers have almost no hope of finding them.

To make published material in a GitHub repo more accessible, we have talked before (and John MacGregor shared a PoC) about using GitHub Pages to generate web-based documentation and/or PDFs.

regards,

Paul

[1] https://github.com/elisa-tech/wg-automotive/blob/master/README.md#contribution-workflow

On 15/02/2022 07:30, Philipp Ahmann wrote:
Hello Shuah, all,
although, I have a customer meeting during the first half of the TSC and can onlyjoin later,I would like to contribute my goal/success ideasg for the year. I believe they also fit to what has been contributed so far.
We have different puzzle pieces within ELISA which we call "work groups". This was well visualized in more than one workshop. Even trials have been made how these work groups should interact. However, I fear that the binding of work groups is still very weak. Use case work groups should contribute to the other work groups and provide input and vise versa. We set goals and give regular reports in TSC meetings where we are within the work group, but we should also report and focus what we have done to serve the other work groups. Which impact does our work make to the other work groups? If we cannot show how how the different groups interact (on engineering not powerpoint level), we will never be able to provide a complete picture. Because one thing is for sure in my perspective: We will need all the existing groups to enable Linux in safety applications.
My proposal and therefore goal is: Make both, the medical and automotive work group use cases, ready to serve as a proper blue print for further use cases during this year. Show where the gaps are, but map existing work packages/artifacts from other groups and link to show how these gaps will be filled. The material generated should show how the work products of all work group interact with each other, and that medical devices and automotive are aligned in the way of documentation, so you can really call results a blueprint. We need to generate the big picture, make on-boarding easier and generate transparency where support is needed by enabling direct "picking up of tasks" from a roadmap and current cycle.
We should also try to reach out to further contributors to get member commitment, but for this we need to have proper material and demands declared.
Best regards,
Philipp
---
Am Mo., 14. Feb. 2022 um 17:24 Uhr schrieb Walt Miner <wminer@... <mailto:wminer@...>>:
I think I am aligned with Elena's goals.  We have been working
towards Goal 1 in the Automotive WG, but progress is slow,
especially given the fact that a number of participants have dropped
out or will be dropping out shortly. I will work with the AGL
community to try to push for more involvement from that community
(aligns with Goal 2) and we have a use case (Instrument Cluster
tell-tale)  that is seemingly simple, but provides a rich set of
implementation details to work through and eventually get to Goal 3.
 I will try to participate in this week's TSC meeting. Generally
AGL has a meeting scheduled at the same time that makes it
impossible for me to attend, but I feel that we are at an important
junction in the ELISA project so I will figure out how to attend the
next few TSC meetings.
Regards,
Walt
Walt Miner
AGL Community Manager
The Linux Foundation
Visit us at:
www.automotivegradelinux.org <http://www.automotivegradelinux.org>
lists.automotivelinux.org <http://lists.automotivelinux.org>
www.linuxfoundation.org <http://www.linuxfoundation.org>
On Thu, Feb 10, 2022 at 8:52 AM <elana.copperman@...
<mailto:elana.copperman@...>> wrote:
I stand corrected.  Perhaps more accurate:____
/Those who are "ok with Linux as is", /believe that they /don't
really need any by-products of ELISA.   They will continue to do
what they are already doing, /unless we communicate the benefits
and feasibility./.____/
__ __
__ __
*From:* Smith, Jason <Jason.Smith@...
<mailto:Jason.Smith@...>>
*Sent:* Thursday, February 10, 2022 3:49 PM
*To:* Elana Copperman <Elana.Copperman@...
<mailto:Elana.Copperman@...>>; Shuah Khan
<skhan@... <mailto:skhan@...>>;
devel@...
*Subject:* RE: [ELISA Technical Community] TSC Meeting Agenda -
February 16 2022____
__ __
*EXTERNAL EMAIL**:*Do not click any links or open any
attachments unless you trust the sender and know the content is
safe.____
Hi Elana,____
__ __
Just wanted to respond to one of your comments:____
__ __
/Those who are "ok with Linux as is", don't really need any
by-products of ELISA.   They will continue to do what they are
already doing.____/
__ __
I don’t believe this is entirely true.____
__ __
More clearly communicating potential shortcomings of Linux to
these folks will enable them to better design a system around
Linux to make that overall system safer.____
__ __
*Jason R. Smith, UL-CFSX
<https://www.ul.com/services/functional-safety-certification-and-training-program>*
Principal Engineer, Robots & Control Systems (CMIT)____
/Distinguished Member of Technical Staff____/
--------------------------------------------------
UL LLC
333 Pfingsten Road
Northbrook, IL 60062-2096 US
T: 1.847.664.1352
W: https://www.ul.com <https://www.ul.com>____
__ __
*From:* Elana Copperman <Elana.Copperman@...
<mailto:Elana.Copperman@...>>
*Sent:* Thursday, February 10, 2022 1:41 AM
*To:* Smith, Jason <Jason.Smith@...
<mailto:Jason.Smith@...>>; Shuah Khan
<skhan@... <mailto:skhan@...>>;
devel@... <mailto:devel@...>
*Subject:* RE: [ELISA Technical Community] TSC Meeting Agenda -
February 16 2022____
__ __
Thanks, Jason.  I think we are pretty much saying the same
thing, only (as usual in ELISA) from 2 different sides of the
coin.____
Those who are "ok with Linux as is", don't really need any
by-products of ELISA.   They will continue to do what they are
already doing.____
For those who need stricter compliance with the standards, it is
already clear that full compliance will not happen.  So that
some iterative process (similar to what Jason describes) will
bring Linux*closer* to what the safety standards expect, leaving
it up to the integrator to fill in any remaining gaps for
his/her use case.  I don't think ELISA can/should do more; but
even this will be a great contribution.____
__ __
My only real concern is that we need to bring in a broader
spectrum of contributors, so that we can expand our context for
deployment and acceptance.  As Jason says, "I don't know if this
is exactly what the community needs".  The community of Linux
users for safety critical applications is enormous, and we have
lost them (they attended the early workshops but have since
petered out).  We need to hear their voice.____
Any proposal, Jason's or mine or anyone else's, is an iterative
process.  But we need to be moving in a clear direction for what
the world needs.____
Regards____
Elana____
__ __
*From:* Smith, Jason <Jason.Smith@...
<mailto:Jason.Smith@...>>
*Sent:* Thursday, February 10, 2022 5:29 AM
*To:* Elana Copperman <Elana.Copperman@...
<mailto:Elana.Copperman@...>>; Shuah Khan
<skhan@... <mailto:skhan@...>>;
devel@... <mailto:devel@...>
*Subject:* RE: [ELISA Technical Community] TSC Meeting Agenda -
February 16 2022____
__ __
*EXTERNAL EMAIL**:*Do not click any links or open any
attachments unless you trust the sender and know the content is
safe.____
My goals are quick wins.  There are safety applications using
Linux that either don’t need safety certification or whose
standards allow Linux to be treated as-is, i.e. software of
unknown pedigree.  Just small improvements to Linux or
relatively small additional pieces of information provided with
Linux could offer a lot of value to these developers, allowing
them to build safer products.  Examples: code improvements, new
modules that add or support software safety measures, white
papers, manuals, design guides, fault analyses, reports
(verification, validation, review, etc.), release notes
including known issues, etc.  In a way, this is perhaps a
scaled-down version of Elana’s (3).____
__ __
That being said… I don’t know if this is exactly what the
community needs.____
__ __
I think (if we haven’t done so already) we should go out far and
wide across not only ELISA but Linux developers in general to
find out what they really need.____
__ __
Are there enough developers of safety applications using Linux
that are okay with treating Linux as-is, making it worthwhile to
pursue my stated goal?____
__ __
Or are most folks trying to develop systems for self-driving
cars using Linux and ultimately need compliance with ISO 26262?____
__ __
If the latter is true, start with Elana’s (1).  It’s going to be
a lot of work.____
__ __
Jason____
__ __
*From:* devel@... <mailto:devel@...>
<devel@... <mailto:devel@...>> *On
Behalf Of *elana.copperman via lists.elisa.tech
*Sent:* Wednesday, February 09, 2022 9:37 AM
*To:* Shuah Khan <skhan@...
<mailto:skhan@...>>; devel@...
<mailto:devel@...>
*Subject:* Re: [ELISA Technical Community] TSC Meeting Agenda -
February 16 2022____
__ __
Thanks, Shuah.  Some goals/ideas from my side:____
1. To establish a framework for communication and collaboration
between Linux kernel developers/maintainers, safety experts
and designers/developers of Linux based safety critical
systems.  Without broader representation and communication,
the work products of ELISA cannot have a context for
deployment and acceptance.____
2. ELISA is a project of the Linux Foundation.  To leverage
this umbrella, learn from its strong points, and help to
improve the weaker points towards the long-term goal of
integrating Linux successfully in safety critical systems.____
3. Work products (actual kernel patches) which will support the
original ELISA mission statement:   to define and maintain a
common set of elements, processes and tools that can be
incorporated into Linux-based, safety-critical systems
amenable to safety certification.____
Regards____
Elana____
------------------------------------------------------------------------
*From:*devel@... <mailto:devel@...>
<devel@... <mailto:devel@...>> on
behalf of Shuah Khan <skhan@...
<mailto:skhan@...>>
*Sent:* Wednesday, February 9, 2022 5:20 PM
*To:* devel@... <mailto:devel@...>
<devel@... <mailto:devel@...>>
*Cc:* Shuah Khan <skhan@...
<mailto:skhan@...>>
*Subject:* [ELISA Technical Community] TSC Meeting Agenda -
February 16 2022 ____
____
EXTERNAL EMAIL: Do not click any links or open any attachments
unless you trust the sender and know the content is safe.
All,
Let's meet next week to discuss alignment on goals and what success
looks like. Please respond to this thread to add you 1 or 2 items
you consider important to achieve ELISA goals and make the project
successful.
I will compile the items and share the consolidated list before the
meeting.
thanks,
-- Shuah
____
__
This e-mail may contain privileged or confidential information.
If you are not the intended recipient: (1) you may not disclose,
use, distribute, copy or rely upon this message or
attachment(s); and (2) please notify the sender by reply e-mail,
and then delete this message and its attachment(s). Underwriters
Laboratories Inc. and its affiliates disclaim all liability for
any errors, omissions, corruption or virus in this message or
any attachments.____
This e-mail may contain privileged or confidential information.
If you are not the intended recipient: (1) you may not disclose,
use, distribute, copy or rely upon this message or
attachment(s); and (2) please notify the sender by reply e-mail,
and then delete this message and its attachment(s). Underwriters
Laboratories Inc. and its affiliates disclaim all liability for
any errors, omissions, corruption or virus in this message or
any attachments.____


Philipp Ahmann
 

Hello Shuah, all,

 

although, I have a customer meeting during the first half of the TSC and can onlyjoin later,I would like to contribute my goal/success ideasg for the year. I believe they also fit to what has been contributed so far.

 

We have different puzzle pieces within ELISA which we call "work groups". This was well visualized in more than one workshop. Even trials have been made how these work groups should interact. However, I fear that the binding of work groups is still very weak. Use case work groups should contribute to the other work groups and provide input and vise versa. We set goals and give regular reports in TSC meetings where we are within the work group, but we should also report and focus what we have done to serve the other work groups. Which impact does our work make to the other work groups? If we cannot show how how the different groups interact (on engineering not powerpoint level), we will never be able to provide a complete picture. Because one thing is for sure in my perspective: We will need all the existing groups to enable Linux in safety applications.

 

My proposal and therefore goal is: Make both, the medical and automotive work group use cases, ready to serve as a proper blue print for further use cases during this year. Show where the gaps are, but map existing work packages/artifacts from other groups and link to show how these gaps will be filled. The material generated should show how the work products of all work group interact with each other, and that medical devices and automotive are aligned in the way of documentation, so you can really call results a blueprint. We need to generate the big picture, make on-boarding easier and generate transparency where support is needed by enabling direct "picking up of tasks" from a roadmap and current cycle.

 

We should also try to reach out to further contributors to get member commitment, but for this we need to have proper material and demands declared.

 

Best regards,

Philipp

---

 


Am Mo., 14. Feb. 2022 um 17:24 Uhr schrieb Walt Miner <wminer@...>:

I think I am aligned with Elena's goals.  We have been working towards Goal 1 in the Automotive WG, but progress is slow, especially given the fact that a number of participants have dropped out or will be dropping out shortly. I will work with the AGL community to try to push for more involvement from that community (aligns with Goal 2) and we have a use case (Instrument Cluster tell-tale)  that is seemingly simple, but provides a rich set of implementation details to work through and eventually get to Goal 3.  

 I will try to participate in this week's TSC meeting. Generally AGL has a meeting scheduled at the same time that makes it impossible for me to attend, but I feel that we are at an important junction in the ELISA project so I will figure out how to attend the next few TSC meetings. 

Regards,
Walt


Walt Miner
AGL Community Manager
The Linux Foundation

Visit us at:




On Thu, Feb 10, 2022 at 8:52 AM <elana.copperman@...> wrote:

I stand corrected.  Perhaps more accurate:

Those who are "ok with Linux as is", believe that they don't really need any by-products of ELISA.   They will continue to do what they are already doing, unless we communicate the benefits and feasibility..

 

 

From: Smith, Jason <Jason.Smith@...>
Sent: Thursday, February 10, 2022 3:49 PM
To: Elana Copperman <Elana.Copperman@...>; Shuah Khan <skhan@...>; devel@...
Subject: RE: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

Hi Elana,

 

Just wanted to respond to one of your comments:

 

Those who are "ok with Linux as is", don't really need any by-products of ELISA.   They will continue to do what they are already doing.

 

I don’t believe this is entirely true.

 

More clearly communicating potential shortcomings of Linux to these folks will enable them to better design a system around Linux to make that overall system safer.

 

Jason R. Smith, UL-CFSX
Principal Engineer, Robots & Control Systems (CMIT)

Distinguished Member of Technical Staff

--------------------------------------------------
UL LLC
333 Pfingsten Road
Northbrook, IL 60062-2096 US
T: 1.847.664.1352
W: https://www.ul.com

 

From: Elana Copperman <Elana.Copperman@...>
Sent: Thursday, February 10, 2022 1:41 AM
To: Smith, Jason <Jason.Smith@...>; Shuah Khan <skhan@...>; devel@...
Subject: RE: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

Thanks, Jason.  I think we are pretty much saying the same thing, only (as usual in ELISA) from 2 different sides of the coin.

Those who are "ok with Linux as is", don't really need any by-products of ELISA.   They will continue to do what they are already doing.

For those who need stricter compliance with the standards, it is already clear that full compliance will not happen.  So that some iterative process (similar to what Jason describes) will bring Linux closer to what the safety standards expect, leaving it up to the integrator to fill in any remaining gaps for his/her use case.  I don't think ELISA can/should do more; but even this will be a great contribution.

 

My only real concern is that we need to bring in a broader spectrum of contributors, so that we can expand our context for deployment and acceptance.  As Jason says, "I don't know if this is exactly what the community needs".  The community of Linux users for safety critical applications is enormous, and we have lost them (they attended the early workshops but have since petered out).  We need to hear their voice.

Any proposal, Jason's or mine or anyone else's, is an iterative process.  But we need to be moving in a clear direction for what the world needs.

Regards

Elana

 

From: Smith, Jason <Jason.Smith@...>
Sent: Thursday, February 10, 2022 5:29 AM
To: Elana Copperman <Elana.Copperman@...>; Shuah Khan <skhan@...>; devel@...
Subject: RE: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

My goals are quick wins.  There are safety applications using Linux that either don’t need safety certification or whose standards allow Linux to be treated as-is, i.e. software of unknown pedigree.  Just small improvements to Linux or relatively small additional pieces of information provided with Linux could offer a lot of value to these developers, allowing them to build safer products.  Examples: code improvements, new modules that add or support software safety measures, white papers, manuals, design guides, fault analyses, reports (verification, validation, review, etc.), release notes including known issues, etc.  In a way, this is perhaps a scaled-down version of Elana’s (3).

 

That being said… I don’t know if this is exactly what the community needs.

 

I think (if we haven’t done so already) we should go out far and wide across not only ELISA but Linux developers in general to find out what they really need.

 

Are there enough developers of safety applications using Linux that are okay with treating Linux as-is, making it worthwhile to pursue my stated goal?

 

Or are most folks trying to develop systems for self-driving cars using Linux and ultimately need compliance with ISO 26262?

 

If the latter is true, start with Elana’s (1).  It’s going to be a lot of work.

 

Jason

 

From: devel@... <devel@...> On Behalf Of elana.copperman via lists.elisa.tech
Sent: Wednesday, February 09, 2022 9:37 AM
To: Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

Thanks, Shuah.  Some goals/ideas from my side:

  1. To establish a framework for communication and collaboration between Linux kernel developers/maintainers, safety experts and designers/developers of Linux based safety critical systems.  Without broader representation and communication, the work products of ELISA cannot have a context for deployment and acceptance.
  2. ELISA is a project of the Linux Foundation.  To leverage this umbrella, learn from its strong points, and help to improve the weaker points towards the long-term goal of integrating Linux successfully in safety critical systems.
  3. Work products (actual kernel patches) which will support the original ELISA mission statement:   to define and maintain a common set of elements, processes and tools that can be incorporated into Linux-based, safety-critical systems amenable to safety certification.

Regards

Elana


From: devel@... <devel@...> on behalf of Shuah Khan <skhan@...>
Sent: Wednesday, February 9, 2022 5:20 PM
To: devel@... <devel@...>
Cc: Shuah Khan <skhan@...>
Subject: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

All,

Let's meet next week to discuss alignment on goals and what success
looks like. Please respond to this thread to add you 1 or 2 items
you consider important to achieve ELISA goals and make the project
successful.

I will compile the items and share the consolidated list before the
meeting.

thanks,
-- Shuah



This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.


This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.


Walt Miner
 

I think I am aligned with Elena's goals.  We have been working towards Goal 1 in the Automotive WG, but progress is slow, especially given the fact that a number of participants have dropped out or will be dropping out shortly. I will work with the AGL community to try to push for more involvement from that community (aligns with Goal 2) and we have a use case (Instrument Cluster tell-tale)  that is seemingly simple, but provides a rich set of implementation details to work through and eventually get to Goal 3.  

 I will try to participate in this week's TSC meeting. Generally AGL has a meeting scheduled at the same time that makes it impossible for me to attend, but I feel that we are at an important junction in the ELISA project so I will figure out how to attend the next few TSC meetings. 

Regards,
Walt


Walt Miner
AGL Community Manager
The Linux Foundation

Visit us at:




On Thu, Feb 10, 2022 at 8:52 AM <elana.copperman@...> wrote:

I stand corrected.  Perhaps more accurate:

Those who are "ok with Linux as is", believe that they don't really need any by-products of ELISA.   They will continue to do what they are already doing, unless we communicate the benefits and feasibility..

 

 

From: Smith, Jason <Jason.Smith@...>
Sent: Thursday, February 10, 2022 3:49 PM
To: Elana Copperman <Elana.Copperman@...>; Shuah Khan <skhan@...>; devel@...
Subject: RE: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

Hi Elana,

 

Just wanted to respond to one of your comments:

 

Those who are "ok with Linux as is", don't really need any by-products of ELISA.   They will continue to do what they are already doing.

 

I don’t believe this is entirely true.

 

More clearly communicating potential shortcomings of Linux to these folks will enable them to better design a system around Linux to make that overall system safer.

 

Jason R. Smith, UL-CFSX
Principal Engineer, Robots & Control Systems (CMIT)

Distinguished Member of Technical Staff

--------------------------------------------------
UL LLC
333 Pfingsten Road
Northbrook, IL 60062-2096 US
T: 1.847.664.1352
W: https://www.ul.com

 

From: Elana Copperman <Elana.Copperman@...>
Sent: Thursday, February 10, 2022 1:41 AM
To: Smith, Jason <Jason.Smith@...>; Shuah Khan <skhan@...>; devel@...
Subject: RE: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

Thanks, Jason.  I think we are pretty much saying the same thing, only (as usual in ELISA) from 2 different sides of the coin.

Those who are "ok with Linux as is", don't really need any by-products of ELISA.   They will continue to do what they are already doing.

For those who need stricter compliance with the standards, it is already clear that full compliance will not happen.  So that some iterative process (similar to what Jason describes) will bring Linux closer to what the safety standards expect, leaving it up to the integrator to fill in any remaining gaps for his/her use case.  I don't think ELISA can/should do more; but even this will be a great contribution.

 

My only real concern is that we need to bring in a broader spectrum of contributors, so that we can expand our context for deployment and acceptance.  As Jason says, "I don't know if this is exactly what the community needs".  The community of Linux users for safety critical applications is enormous, and we have lost them (they attended the early workshops but have since petered out).  We need to hear their voice.

Any proposal, Jason's or mine or anyone else's, is an iterative process.  But we need to be moving in a clear direction for what the world needs.

Regards

Elana

 

From: Smith, Jason <Jason.Smith@...>
Sent: Thursday, February 10, 2022 5:29 AM
To: Elana Copperman <Elana.Copperman@...>; Shuah Khan <skhan@...>; devel@...
Subject: RE: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

My goals are quick wins.  There are safety applications using Linux that either don’t need safety certification or whose standards allow Linux to be treated as-is, i.e. software of unknown pedigree.  Just small improvements to Linux or relatively small additional pieces of information provided with Linux could offer a lot of value to these developers, allowing them to build safer products.  Examples: code improvements, new modules that add or support software safety measures, white papers, manuals, design guides, fault analyses, reports (verification, validation, review, etc.), release notes including known issues, etc.  In a way, this is perhaps a scaled-down version of Elana’s (3).

 

That being said… I don’t know if this is exactly what the community needs.

 

I think (if we haven’t done so already) we should go out far and wide across not only ELISA but Linux developers in general to find out what they really need.

 

Are there enough developers of safety applications using Linux that are okay with treating Linux as-is, making it worthwhile to pursue my stated goal?

 

Or are most folks trying to develop systems for self-driving cars using Linux and ultimately need compliance with ISO 26262?

 

If the latter is true, start with Elana’s (1).  It’s going to be a lot of work.

 

Jason

 

From: devel@... <devel@...> On Behalf Of elana.copperman via lists.elisa.tech
Sent: Wednesday, February 09, 2022 9:37 AM
To: Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

Thanks, Shuah.  Some goals/ideas from my side:

  1. To establish a framework for communication and collaboration between Linux kernel developers/maintainers, safety experts and designers/developers of Linux based safety critical systems.  Without broader representation and communication, the work products of ELISA cannot have a context for deployment and acceptance.
  2. ELISA is a project of the Linux Foundation.  To leverage this umbrella, learn from its strong points, and help to improve the weaker points towards the long-term goal of integrating Linux successfully in safety critical systems.
  3. Work products (actual kernel patches) which will support the original ELISA mission statement:   to define and maintain a common set of elements, processes and tools that can be incorporated into Linux-based, safety-critical systems amenable to safety certification.

Regards

Elana


From: devel@... <devel@...> on behalf of Shuah Khan <skhan@...>
Sent: Wednesday, February 9, 2022 5:20 PM
To: devel@... <devel@...>
Cc: Shuah Khan <skhan@...>
Subject: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

All,

Let's meet next week to discuss alignment on goals and what success
looks like. Please respond to this thread to add you 1 or 2 items
you consider important to achieve ELISA goals and make the project
successful.

I will compile the items and share the consolidated list before the
meeting.

thanks,
-- Shuah



This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.


This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.


elana.copperman@...
 

I stand corrected.  Perhaps more accurate:

Those who are "ok with Linux as is", believe that they don't really need any by-products of ELISA.   They will continue to do what they are already doing, unless we communicate the benefits and feasibility..

 

 

From: Smith, Jason <Jason.Smith@...>
Sent: Thursday, February 10, 2022 3:49 PM
To: Elana Copperman <Elana.Copperman@...>; Shuah Khan <skhan@...>; devel@...
Subject: RE: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

Hi Elana,

 

Just wanted to respond to one of your comments:

 

Those who are "ok with Linux as is", don't really need any by-products of ELISA.   They will continue to do what they are already doing.

 

I don’t believe this is entirely true.

 

More clearly communicating potential shortcomings of Linux to these folks will enable them to better design a system around Linux to make that overall system safer.

 

Jason R. Smith, UL-CFSX
Principal Engineer, Robots & Control Systems (CMIT)

Distinguished Member of Technical Staff

--------------------------------------------------
UL LLC
333 Pfingsten Road
Northbrook, IL 60062-2096 US
T: 1.847.664.1352
W: https://www.ul.com

 

From: Elana Copperman <Elana.Copperman@...>
Sent: Thursday, February 10, 2022 1:41 AM
To: Smith, Jason <Jason.Smith@...>; Shuah Khan <skhan@...>; devel@...
Subject: RE: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

Thanks, Jason.  I think we are pretty much saying the same thing, only (as usual in ELISA) from 2 different sides of the coin.

Those who are "ok with Linux as is", don't really need any by-products of ELISA.   They will continue to do what they are already doing.

For those who need stricter compliance with the standards, it is already clear that full compliance will not happen.  So that some iterative process (similar to what Jason describes) will bring Linux closer to what the safety standards expect, leaving it up to the integrator to fill in any remaining gaps for his/her use case.  I don't think ELISA can/should do more; but even this will be a great contribution.

 

My only real concern is that we need to bring in a broader spectrum of contributors, so that we can expand our context for deployment and acceptance.  As Jason says, "I don't know if this is exactly what the community needs".  The community of Linux users for safety critical applications is enormous, and we have lost them (they attended the early workshops but have since petered out).  We need to hear their voice.

Any proposal, Jason's or mine or anyone else's, is an iterative process.  But we need to be moving in a clear direction for what the world needs.

Regards

Elana

 

From: Smith, Jason <Jason.Smith@...>
Sent: Thursday, February 10, 2022 5:29 AM
To: Elana Copperman <Elana.Copperman@...>; Shuah Khan <skhan@...>; devel@...
Subject: RE: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

My goals are quick wins.  There are safety applications using Linux that either don’t need safety certification or whose standards allow Linux to be treated as-is, i.e. software of unknown pedigree.  Just small improvements to Linux or relatively small additional pieces of information provided with Linux could offer a lot of value to these developers, allowing them to build safer products.  Examples: code improvements, new modules that add or support software safety measures, white papers, manuals, design guides, fault analyses, reports (verification, validation, review, etc.), release notes including known issues, etc.  In a way, this is perhaps a scaled-down version of Elana’s (3).

 

That being said… I don’t know if this is exactly what the community needs.

 

I think (if we haven’t done so already) we should go out far and wide across not only ELISA but Linux developers in general to find out what they really need.

 

Are there enough developers of safety applications using Linux that are okay with treating Linux as-is, making it worthwhile to pursue my stated goal?

 

Or are most folks trying to develop systems for self-driving cars using Linux and ultimately need compliance with ISO 26262?

 

If the latter is true, start with Elana’s (1).  It’s going to be a lot of work.

 

Jason

 

From: devel@... <devel@...> On Behalf Of elana.copperman via lists.elisa.tech
Sent: Wednesday, February 09, 2022 9:37 AM
To: Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

Thanks, Shuah.  Some goals/ideas from my side:

  1. To establish a framework for communication and collaboration between Linux kernel developers/maintainers, safety experts and designers/developers of Linux based safety critical systems.  Without broader representation and communication, the work products of ELISA cannot have a context for deployment and acceptance.
  2. ELISA is a project of the Linux Foundation.  To leverage this umbrella, learn from its strong points, and help to improve the weaker points towards the long-term goal of integrating Linux successfully in safety critical systems.
  3. Work products (actual kernel patches) which will support the original ELISA mission statement:   to define and maintain a common set of elements, processes and tools that can be incorporated into Linux-based, safety-critical systems amenable to safety certification.

Regards

Elana


From: devel@... <devel@...> on behalf of Shuah Khan <skhan@...>
Sent: Wednesday, February 9, 2022 5:20 PM
To: devel@... <devel@...>
Cc: Shuah Khan <skhan@...>
Subject: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

All,

Let's meet next week to discuss alignment on goals and what success
looks like. Please respond to this thread to add you 1 or 2 items
you consider important to achieve ELISA goals and make the project
successful.

I will compile the items and share the consolidated list before the
meeting.

thanks,
-- Shuah



This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.


This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.


Smith, Jason
 

Hi Elana,

 

Just wanted to respond to one of your comments:

 

Those who are "ok with Linux as is", don't really need any by-products of ELISA.   They will continue to do what they are already doing.

 

I don’t believe this is entirely true.

 

More clearly communicating potential shortcomings of Linux to these folks will enable them to better design a system around Linux to make that overall system safer.

 

Jason R. Smith, UL-CFSX
Principal Engineer, Robots & Control Systems (CMIT)

Distinguished Member of Technical Staff

--------------------------------------------------
UL LLC
333 Pfingsten Road
Northbrook, IL 60062-2096 US
T: 1.847.664.1352
W: https://www.ul.com

 

From: Elana Copperman <Elana.Copperman@...>
Sent: Thursday, February 10, 2022 1:41 AM
To: Smith, Jason <Jason.Smith@...>; Shuah Khan <skhan@...>; devel@...
Subject: RE: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

Thanks, Jason.  I think we are pretty much saying the same thing, only (as usual in ELISA) from 2 different sides of the coin.

Those who are "ok with Linux as is", don't really need any by-products of ELISA.   They will continue to do what they are already doing.

For those who need stricter compliance with the standards, it is already clear that full compliance will not happen.  So that some iterative process (similar to what Jason describes) will bring Linux closer to what the safety standards expect, leaving it up to the integrator to fill in any remaining gaps for his/her use case.  I don't think ELISA can/should do more; but even this will be a great contribution.

 

My only real concern is that we need to bring in a broader spectrum of contributors, so that we can expand our context for deployment and acceptance.  As Jason says, "I don't know if this is exactly what the community needs".  The community of Linux users for safety critical applications is enormous, and we have lost them (they attended the early workshops but have since petered out).  We need to hear their voice.

Any proposal, Jason's or mine or anyone else's, is an iterative process.  But we need to be moving in a clear direction for what the world needs.

Regards

Elana

 

From: Smith, Jason <Jason.Smith@...>
Sent: Thursday, February 10, 2022 5:29 AM
To: Elana Copperman <Elana.Copperman@...>; Shuah Khan <skhan@...>; devel@...
Subject: RE: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

My goals are quick wins.  There are safety applications using Linux that either don’t need safety certification or whose standards allow Linux to be treated as-is, i.e. software of unknown pedigree.  Just small improvements to Linux or relatively small additional pieces of information provided with Linux could offer a lot of value to these developers, allowing them to build safer products.  Examples: code improvements, new modules that add or support software safety measures, white papers, manuals, design guides, fault analyses, reports (verification, validation, review, etc.), release notes including known issues, etc.  In a way, this is perhaps a scaled-down version of Elana’s (3).

 

That being said… I don’t know if this is exactly what the community needs.

 

I think (if we haven’t done so already) we should go out far and wide across not only ELISA but Linux developers in general to find out what they really need.

 

Are there enough developers of safety applications using Linux that are okay with treating Linux as-is, making it worthwhile to pursue my stated goal?

 

Or are most folks trying to develop systems for self-driving cars using Linux and ultimately need compliance with ISO 26262?

 

If the latter is true, start with Elana’s (1).  It’s going to be a lot of work.

 

Jason

 

From: devel@... <devel@...> On Behalf Of elana.copperman via lists.elisa.tech
Sent: Wednesday, February 09, 2022 9:37 AM
To: Shuah Khan <skhan@...>; devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

Thanks, Shuah.  Some goals/ideas from my side:

  1. To establish a framework for communication and collaboration between Linux kernel developers/maintainers, safety experts and designers/developers of Linux based safety critical systems.  Without broader representation and communication, the work products of ELISA cannot have a context for deployment and acceptance.
  2. ELISA is a project of the Linux Foundation.  To leverage this umbrella, learn from its strong points, and help to improve the weaker points towards the long-term goal of integrating Linux successfully in safety critical systems.
  3. Work products (actual kernel patches) which will support the original ELISA mission statement:   to define and maintain a common set of elements, processes and tools that can be incorporated into Linux-based, safety-critical systems amenable to safety certification.

Regards

Elana


From: devel@... <devel@...> on behalf of Shuah Khan <skhan@...>
Sent: Wednesday, February 9, 2022 5:20 PM
To: devel@... <devel@...>
Cc: Shuah Khan <skhan@...>
Subject: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022

 

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

All,

Let's meet next week to discuss alignment on goals and what success
looks like. Please respond to this thread to add you 1 or 2 items
you consider important to achieve ELISA goals and make the project
successful.

I will compile the items and share the consolidated list before the
meeting.

thanks,
-- Shuah




This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.


This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.