The Linux Foundation Projects
Skip to main content
All Posts By

elisaproject

Recap of the ELISA November Workshop

By Blog, Workshop

Written by Philipp Ahmann, ELISA Project Ambassador and TSC member

The 8th ELISA Workshop, which took place on November 8-10, had 158 registrants that learned more about the various working groups and networked with ambassadors. Participants were active and stable in the technical discussions, which helped plan for next year, and proved that there is continuous interest and motivations in these topics. Additionally, new ideas were shared and can be considered as sources of inspiration and for critical thinking with e.g. talks about STPA, the z-model or open source and the community problem along with new approaches to safety and importance of processes and testing.

Overall, ELISA workshops have more of a conference character presenting major achievements and results of achievements from the last quarter. Interested newcomers as well as community participants receive a very good status update in which direction ELISA moves forward on its way to enable Linux in safety applications. 

On the other hand, this brilliant forum to sync up and align in a virtual format, misses a bit of the in-person discussion and brainstorming that made ELISA’s first workshops so enjoyable. With a community spread across the world longer working sessions are seldom and almost not possible. Prime time slots are used to align to reach as many people as possible.

As this year’s workshops come to a close, we hope that travelling and hybrid workshops become possible again. In this type of format, the core community can take joint working sessions, while talks and presentations can still attract newcomers and other interested to get an overview about what is going on in the community and what to target next. We hope to see you in-person next year if possible. 

In case you missed the November virtual workshop, let us take a look at a few selected sessions from the conference. 

Day 1 started with the newcomer and welcome session. It provided an overview about what Linux is and how safety comes into picture to form the name ELISA. The statistics shown during the talk on the usage of Linux in industry are quite impressive and speak for themselves. Linux is everywhere. (Or almost everywhere.)

Additionally, new details about two new working groups were presented – Linux Features for Safety Critical Systems Working Group and Open Source Engingeering Process Working Group. Originally, these two groups started as one but as the group grew and evolved two streams were observed and needed. Both are in good hands, with Paul Albertella from Codethink, which will continue to focus on the actual open source development process and Elana Copperman from Mobileye/Intel will start concentrating on Linux features for safety-critical systems.

How important such Linux features and development processes are could be slightly depicted from the presentation about Linux in Safety Systems explained by Christopher Temple from arm. He illustrates quite well which different levels of complexity a system could have. He also reminded the audience that there can be a difference between simply following a safety integrity standard for the necessary processes and actually creating a safe product. It is interesting to see that you may be able to show standard conformance without having safety properly implemented and creating a safe system which is not certifiable or in conformance with a safety standard.

On the second day the slides about Certification Using the New Approach to Safety presented by Paul Albertella showed that modern safety certification and assessments need to bring a good tool support towards tool support and automation along with proper tool classification and qualification as a major step to achieve efficient certification and generation of evidence, irrespective if you are running proprietary or open source software. 

In another session Lukas Bulwahn from Elektrobit helped the participants on understanding the z-model in which the challenge on pre-existing software is illustrated, where a logical model would be to write requirements, go over to integration and verification to derive software architectural design, leading to software unit verification to finally create a “z” by moving to the originally existing Software unit design and implementation. This can help to approach existing stacks which do not fall into strict recommendations such as demanded by e.g. ISO26262. This said, it has to be kept in mind that the “z” fills the gap and can create a complete “v” in the end, although you may run into issues during an ASPICE assessment.

Day two was concluded by Shaun Mooney from Codethink, who gave insights on how to use STPA for ISO26262. STPA has been used within the medical devices work group since a long time and recently found its way also into the automotive work group, where it serves as an alternative to a traditional HARA. A very important element of the STPA, beside others, is the identification of unsafe control actions (UCA) to unveil potential harms/hazards and risks in a very structured and visual way.

Day three was a nice mixture of technical insights into the Linux kernel and new approaches and directions towards safety qualification of Linux application. The strong demand to consider both Linux software development within the community and the strict regulations by safety integrity standards to come to a certifiable product, were brought to the point by Lukas Bulwahn’s talk. It was thought to encourage critical thinking on safety integrity standards and the community problem. Let us hope that the work of ELISA can make a difference and the effort we take will direct in the solution of this problem, eventually even with updated or new safety integrity standards, which include state of the art software development process and quality measures, so much needed for complex systems.

As for the previous workshops the last session wraps up and includes the goal settings for the next quarter along with the request to not let the discussions stop here…

If you reach this point of reading the blog post, you seem to be really interested in joining the ELISA community, so don’t miss to register to your mailing list of choice.

Short TL:DR summarizing words about the workshop:

  • Less registered people, but very stable number of attendees during the workshop and on level of last workshop
  • Good “take home” messages letting you think about the challenges of Linux and open source communities to approach safety integrity standards
  • New approaches in fields of architectural analysis, tools, development process, testing and engineering show the demands where Linux and open source need to go different ways and where safety integrity standards need to evolve to keep up with the complexity of software written by a large scale community.
  • ELISA community would benefit from a hybrid approach enabling in person working sessions to let the workshop be a workshop and have less conference style.
  • The ELISA community grows and reaches a point where harmonization is needed. Brainstorming times are over and everybody shares concepts and proposals how to achieve the goal to enable Linux in safety applications.

Videos and recordings of the workshop presentations can be found here

Lock in Best Pricing of the Year on Linux Foundation Training & Certification for Cyber Monday

By Blog, LF Training & Certification

Written by Dan Brown, Senior Manager, Content & Social Media, LF Training

As we approach a new year, this is the perfect time to consider what you want your career to look like in 2022. Job openings are at record highs, and this is especially true in the IT field, where the 2021 Open Source Jobs Report found that 92% of hiring managers are unable to find enough talent to meet their organizations’ needs. A primary mission of The Linux Foundation is helping close the talent gap so the industry has the talent necessary to carry out digital transformation activities and continue innovating, while also creating accessible pathways for anyone who wants to start an IT career to do so.

We are excited to once again offer our best pricing of the year on our entire catalog of training courses, certification exams, bundled programs, and bootcamps for Cyber Monday. From now through December 6, 2021, all these fantastic offerings covering hot topics like cloud computing, system administration, networking, blockchain, web development, embedded systems, and more are available at significantly reduced cost. As the home of some of the most important open source technologies like Kubernetes, Linux, Node.js, Hyperledger, and more, The Linux Foundation provides vendor-neutral training directly from the experts helping build these projects.

This year’s Cyber Monday offers include:

Bootcamps (Save 65%. Use Code: CYBER21BC)

PowerBundles (Save 65%. Use Code: CYBER21PB)

Pricing:  Pricing is $1150 $399

  1. LF258+CKA with LFD259+CKAD
  2. LFS200+LFCA with LFS201+LFCS 
  3. LFS258+CKA+LFS260+CKS
  4. LFS250+KCNA+LFS258+CKA
  5. LFW211+JSNAD+LFW212+JSNSD

Bundles (Save 65%. Use Code: CYBER21BUN)

Pricing:  Pricing is $575 $199 except LFCA+LFS200 and KCNA+LFS250 are $299 $105

  1. CKA+LFS258 – Kubernetes Admin
  2. LFCS+LFS201 – Linux SysAdmin
  3. CKS+LFS260 – Kubernetes Security
  4. CKA+CKS – Kubernetes Administration and Security
  5. LFD259+CKAD – Kubernetes Developer
  6. JSNAD+LFW211 – Node.js. Application Developer
  7. JSNSD+LFW212 – Node.js Services Developer
  8. LFS272+CHFA – Hyperledger Fabric Admin
  9. LFD272+CHFD – Hyperledger Fabric Developer
  10. LFS232+CFCD – Cloud Foundry Developer

Bundles (Save 65%. Use Code: CYBER21NEW)

Pricing:  Pricing is $299 $105 for LFCA+LFS200 and KCNA+LFS250; $425 $149 for LFCA+KCNA

  1. LFCA+ LFS200 – Entry-Level IT
  2. KCNA+LFS250 – Entry-Level Cloud Native
  3. KCNA + LFCA – Entry-Level IT and Cloud Native

Certifications (Save 50%. Use Code: CYBER21CC)

Pricing: Pricing is $375 $187.50 for most certifications; $250 $125 for LFCA and KCNA

View the certification catalog

You can check out the full details of everything that is on offer on our Cyber Monday Landing Page. Begin your journey to a long-term, successful career in IT today!

ELISA’s New Linux Features for Safety-Critical Systems Working Group

By Blog, Working Group, Workshop

Written by Elana Copperman, ELISA project ambassador, Chair of the Linux Features for Safety-Critical Systems Working Group and System Safety Architect at Mobileye (Intel)

The Linux Features for Safety-Critical Systems (LFSCS) WG aims to feed into the OSEP and other WGs, working together as a team.  LFSCS invites engineers, architects and integrators who actually develop and deploy Linux-based safety-critical systems to contribute from their practical experience and knowledge.  In particular, to identify existing Linux kernel features that may be leveraged for use in safety-critical systems.  

For example:

  1. Mechanisms for protection of various memory types;  e.g. protection from faults due to uninitialized variables or stack overflow.
  2. Dynamic analysis for multi-threaded systems; e.g. tests based on tools such as TSAN or ASAN.
  3. Kernel profiling using ebpf-based tools; e.g.  perf-tools or bpftrace
  4. AER (Advanced Error Reporting) for fault handling; e.g. PCIe fault handling
  5. Safety extensions to Linux drivers; e.g. fault handling support and bridging the gap between hardware-based safety features and application layer fault handling.

The WG mailing list is open to registration here, and we are seeing an amazing group of contributors who can demonstrate use of such features in real systems, and help ELISA to learn from these experiences.  Initially, we will investigate existing features but will also propose enhancements to such features and to work as a community to design / implement / deploy kernel patches.  The goal of such patches will be to help make those features more amenable for use in safety critical systems.  Our Github playground is here.

The alliance with ELISA, and with the new Open Source Engineering Process Working Group in particular, is a critical aspect of this effort.  We will be working together to help ensure that those patches and features can be used by designers and integrators producing safety critical systems.

 The scope of this WG does not include safety qualification or any safety claims on how the integrator can or should use these features or patches.  The only claims that would be made are a description of the feature and its functional impact.

The WG will be formally kicked off at the upcoming ELISA workshop (November 8-10). We will be giving an overview of the working group and answer any questions on November 8 at 3 pm CET.  We will be scheduling weekly meetings following the workshop.  If the technical challenge of enabling real change in deploying open source Linux-based software for safety critical systems excites you, come join and help us meet the challenges!

You can still register for the Fall workshop, which is being held virtually and is free to attend. All registrants will be able to watch the sessions on-demand. Register here today!

ELISA’s Open Source Engineering Process Working Group

By Blog, Working Group, Workshop

Written by Paul Albertella, Chair of the ELISA Project Open Source Engineering Process Working Group

The ELISA Project’s new Open-Source Engineering Process (OSEP) Working Group focuses on the role of engineering processes in creating safety-related systems based on Linux and other FOSS.

Engineering processes are very important in safety, because we rely heavily on them to provide confidence in a system and its components. We achieve confidence by undertaking risk analysis to identify how harm may result from the use (or misuse) of the system, and then constructing a safety argument, which describes how these risks are managed.

When we apply this approach to a specific element of the system, such as a software component like Linux, the argument can be broken down into a number of claims that we want to make regarding that element and its role in the safety of our system. Some claims will relate to the functional responsibilities that the element has in the system; others will relate to the processes that we use to create and refine it.

Importantly, we also need to produce evidence to support these claims. Almost all of this evidence will be produced by an engineering process; some of it will be evidence relating to those processes themselves..

Safety standards like ISO 26262 and IEC 61508 describe reference processes that can act as a template for safety arguments like this. They identify the engineering practices that are seen be necessary (e.g. code review, verification through software testing), the formal processes that are used to control these (e.g. verification management), and the evidence needed to confirm that these have been applied (e.g. test plans, test results).

These reference processes are based on the V-model, which emphasises the formal specification of requirements, architecture and design, and the ability to trace formal verification processes back to these. For software, the standards focus on the processes used when developing new components for a safety-related system, although they include some guidance on applying the principles to pre-existing components, such as software libraries.

Open source projects like Linux have their own development processes,  which may be   sophisticated and make use of sound software engineering practices. However, it is difficult to map these directly to the reference processes described by the safety standards, because open source development models have very different goals and organizational models, which tend to emphasize refinement by rapid iteration, peer review and community contribution.

In order to address this, OSEP aims to identify and evaluate practices, processes and tools that FOSS developers, system integrators and product creators can use to bridge this gap. We plan to accomplish this by:

  • Selecting Linux topics and safety-related claims that we want to make about them
  • Identifying and evaluating practices, processes and tools to answer:
    • What risks are associated with the topic and claims?
    • To what extent are these risks addressed or mitigated by (or for) Linux?
    • How can we manage risks that are not sufficiently addressed or mitigated?
    • How can we show evidence to support our claims?
  • Collaborating with other WGs for technical investigations
  • Documenting and sharing our results as we go

If you would like to learn more about OSEP, join us for an overview presentation on November 8 at 3 pm CET at the ELISA Workshop. The Fall workshop, being held virtually on November 8-10,  is free to attend and all registrants will be able to watch the sessions on-demand. Register here.

If you would like to contribute to OSEP, please join the mailing list here, where you can also find details of weekly meetings on the working group calendar.

Updated w/ Video: Where do Security and Safety Meet?

By Blog, Industry Conference

Written by Elana Copperman, ELISA project ambassador and System Safety Architect at Mobileye (Intel)

This blog has been updated with the video from the Linux Security Summit (LSS), which took place on September 29-October 1.

Are you attending the upcoming Embedded Linux Conference (ELC) on September 27-30 or the Linux Security Summit (LSS) on September 29-October 1? This year, attendees have the option of joining the conference on-site in Seattle, Washington or virtually from their homes and workplaces.  


As an ELISA ambassador, I will be representing the ELISA Project on Thursday Sept 30 at 11:05 am PDT in a virtual presentation titled “Where do Security and Safety Meet?

Security and Safety have common goals, yet often follow divergent development paths.  We will take a look at various Linux features which were originally designed for security, investigating if/how these features may be relevant to enable safety critical applications.  

For example, we’ll discuss: 

  • Memory protection features
  • Isolation techniques and FFI (Freedom From Interference)
  • Timing and execution
  • ebpf and profiling
  • Safety extensions to Linux drivers

I will present practical implications –  focusing on where security and safety meet and where they don’t meet.  The presentation, which is intended for experienced software developers and architects, will focus on how these features may be used in real systems.  The goal is to spark discussion on how safety mechanisms may be designed in Linux-based safety critical systems, by learning from solutions in the security domain. Watch the video below or check out the presentation here.

Click here to register for the Linux Security Summit or here to learn more about the conference. 

Welcome to the ELISA Project Technical Steering Committee!

By Blog, Technical Update

Written by Shuah Khan, Chair of the ELISA Project Technical Steering Committee

Please join me in welcoming Jason Smith, Paul Albertella and Philipp Ahmann to the ELISA TSC. They have made significant contributions to the ELISA project and their addition will strengthen the TSC and help us continue to make progress with our mission.

A brief summary of their background and contributions are as follows:

Jason Smith

Jason Smith, the Principal Engineer for Robotics and Control Systems Consumer Technology at UL LLC., has:

– Participated in ELISA since the launch of the project in 2019

– Contributed a Linux in Basic Safety White paper to the project

– Participates in the Medical Devices Working Group regularly

 – Contributed the analysis of 62304 SOUP

– Speaks frequently at ELISA Workshops and is an ELISA ambassador

Paul Albertella

Paul Albertella, Consultant at Codethink, has:

– Participated in ELISA since the inception.

– Presented technical content at the last two ELISA workshops

– Contributes in the TSC and other working groups, where he’s been a constructive collaborator

– 20+ years of software engineering experience and understands the open source ecosystem challenges

Philipp Ahmann

Philipp Ahmann, a manager at ADIT (a joint venture of Robert Bosch GmbH and DENSO Corporation) has:

– Participated in ELISA since the start of the project

– Took the lead in helping the project to improve communication and set up our LinkedIn presence

– Volunteered to be an active ambassador on behalf of the project

– Participates in the TSC and other working groups, where he’s known to be a very constructive contributor with an excellent overview across all the different areas we’re working on

– Demonstrates a helpful attitude by being willing to step in and host meetings when the chair is not available

– He is able to actively listen, and helps bring focus to the key elements we need for the project

I look forward to collaborating more closely with all three of our new TSC members. As a reminder, all are welcome to join the bi-weekly public technical community meeting and to contribute your perspectives. You can find the meeting details and subscribe to the calendar here: https://lists.elisa.tech/g/devel/calendar.

Architecture Working Group: A report on Kernel FFI (Freedom From Interference) and some philosophical musings

By Blog, Working Group

Written by Eli Gurvitz,  ELISA Project Ambassador and Functional Safety Architect at Intel (Mobileye)

In a functional safety system FFI is required when the system consists of elements of different Safety Integrity Levels (ASIL).This is to ensure that elements allocated with a lower ASIL do not interfere with elements allocated with a higher ASIL; if FFI cannot be demonstrated the lower ASIL elements must be upgraded to the higher ASIL.

The Architecture Working Group has been discussing “Freedom From Interference (FFI)” in the last several meetings and is considering two aspects:

  • FFI between user space processes allocated with different ASIL
  • FFI between Linux Kernel components/drivers/subsystems allocated with different ASIL

This blog post focuses on the second bullet.

FFI is a key goal of a possible Safety Concept for Linux because Linux is too complex and has too many features, thus considering Linux as a single element of a certain ASIL would result in a very high functional safety qualification effort. If the application runs in a single threaded process and handles interrupts synchronously, then it may be possible to avoid allocating Safety Requirements to the OS and mitigate all failures with application-level safety mechanisms. But this kind of use requires just a simple OS and Linux is an overkill. Using Linux in the way it was meant to be used means it will be the OS of a multi-core SoC that runs many processes with different requirements of different ASILs.

This mode of use is referred to in ISO 26262 part 6 section 7.4.8:

This section refers to ISO 26262 part 9 Clause 6 “Criteria for co-existence of elements”. This clause states:

The Architecture WG investigation considers the Linux kernel partitioned into  sub-elements of mixed criticality, therefore the goal is to show FFI between the sub-elements. The approach to FFI that is currently being discussed in the Architecture WG was developed by ELISA Project members Mobileye and BMW.  

The first step in demonstrating FFI between safety-related and non-safety-related sub-elements is to identify the sub-elments and to allocate them with an ASIL. Since we are analyzing a SW component, the sub-elements are functional areas (or features) of the kernel, e.g. memory management or file systems, and they are made of C language functions. We classify the C functions according to the allocated ASIL by using the Call Tree Tool.

The goal of Call Tree is to statically generate the tree of function calls departing from a specified input one; hence starting for example from a syscall, Call Tree would generate the tree of all invoked functions. Call Tree scans the Linux source code by using the GNU CFlow utility and generates an SQLite database that contains all functions and their calling relations – this provides an almost full call-tree for every C function. 

To classify every Kernel function we allocate Kernel entrypoints (syscalls and interrupt handlers) with safety requirements and associated ASIL; hence every function falling in a certain tree inherits the ASIL associated with the top level entrypoint. If a function is present in multiple trees, it is then assigned with the highest ASIL across those allocated to the different trees.

For example, if there’s a safety requirement for “safe dynamic memory” then we consider the related system calls – mmap, sbrk – as safety related. The union of all functions in the call trees of mmap and sbrk are considered SR and inherit the ASIL allocated to mmap and sbrk.

Once we have partitioned the Kernel the next step is to consider the possible types of interference. These types are defined in Annex D or ISO 26262 part 6. There are three types of interference:

  • Temporal – interference related to time or scheduling. The most common case is when one kernel thread prevents other threads from getting CPU cycles, thereby causing delays. Another example is a process crashing.
  • Spatial – interference related to space, or memory. For example, a lower ASIL driver  may corrupt a kernel data structure.
  • Communication – normally this type of interference relates to transfer of data between two entities over a communication channel. In our analysis we consider static and global variables and pointers as communication channels between sub-elements of the kernel.

The Architecture Working Group plans to deal with all types of interference and currently we are considering the third type – communication interference. We are looking at areas where the internal state of the kernel can be corrupted because of the interaction between NSR and SR C functions (or more generally, C functions of different ASIL ratings). 

The internal state of the kernel consists of many persistent data structures. These data structures, for example linked lists, are pointed to by global and static variables and pointers. Corruption of these data structures can occur in different ways.

Data structures that are accessed via global variables can be corrupted when a lower ASIL function (for example a driver that is rated as ASIL QM) accesses the same data structure that is also used by an ASIL-B function, as depicted in the diagram below. 

Corruption of data structures that are accessed via static variables can occur when a static variable is used by a higher ASIL (or SR) function but this function is used by a lower ASIL (or NSR) function. The NSR function may pass a faulty argument to the SR function and the SR function may use this argument to modify the data structure. The faulty data structure is later used in a safety-related flow. This failure mode is depicted in the diagram below.

This description is only a preliminary formulation of the concept of communication interference within the kernel. The working group is debating the correct use of terms, the concept itself, the correct use of the Call Tree Tool and the selection of ASIL rated system calls for our sample automotive use case – The Tell-Tale signal.

If you are interested in safety engineering, the Linux kernel, or both, then please join us in these discussions. The nice thing about applying the existing Functional Safety standards to the Linux kernel is that there’s plenty of space and freedom for creativity, as these standards were designed for much simpler HW and very much simpler SW. It is as if there’s a written tradition of Safety architecture – the ISO 26262 standard and an Oral interpretation of it which creates a more modern tradition of Safety. You can be a part of creating this tradition. I should also take back the word “creativity” I used four lines above because it will certainly trigger a hot debate around the question of whether Safety likes “creativity” or hates it. So I’ll clarify that we are trying to be creative in a conservative way.

Learn more about the ELISA Architecture Working Group or any of the other groups in this white paper.

A Guided Tour Through the PREEMPT RT castle

By Blog, Workshop

In May, the ELISA Project hosted its 7th Workshop with 239 participants from 37 different countries. For a complete recap of the workshop, click here. Today, we’ll take a look at one of the sessions titled “A Guided Tour Through the PREEMPT RT castle” presented by Thomas Gleixner, CTO at Linutronix GmbH.

The tour through the inner workings of PREEMPT_RT will start at the observation deck to give an conceptual overview. From there it will take the participants through the various chambers which contain a broad range of historic and contemporary operating system technologies. The tour will not only take the hallways it is also going to explore some of the secret passages and the brave-hearted can take a glimpse at the horror cabinets.

General knowledge about operating system concepts is recommended for taking the tour, but of course it’s open for everyone and all chambers have exit doors if it gets too spooky.

ELISA and AUTOSAR Adaptive Brainstorm

By Blog, Workshop

In May, the ELISA Project hosted its 7th Workshop with 239 participants from 37 different countries. For a complete recap of the workshop, click here. Today, we’ll take a look at one of the sessions titled “ELISA and AUTOSAR Adaptive Brainstorm” led by Philipp Ahmann, ADIT GmbH, Huzaifa Saadat, Autosar Experts & Wolfgang Schramm, Continental AG.

AUTOSAR (AUTomotive Open System ARchitecture) is a worldwide development partnership of vehicle manufacturers, suppliers, service providers and companies from the automotive electronics, semiconductor and software industry. The ELISA Project started working more closely with AUTOSAR and Automotive Grade Linux (AGL) and now has a Working Group dedicated to this collaboration.

The AUTOSAR Consortium Working Group Safety works closely with the ELISA Project Automotive Working Group. Previously, the group collaborated to figure out which requirements are put to the system and if assumptions from the Automotive WG can fit with AAUTOSAR expectations. The discussions with AUTOSTAR should harden the work within the ELISA Automotive WG. In this workshop video, Philipp Ahmann, Huzaifa and Wolfgang discuss the work within the ELISA Project, collaboration and host a brainstorm about next steps and more. Watch it here:

Click here learn more about the ELISA Project, here for the Working Groups and here to join our mailing list. 

A Maintainable and Scalable Kernel Qualification Approach for Automotive

By Blog, Workshop

In May, the ELISA Project hosted its 7th Workshop with 239 participants from 37 different countries. For a complete recap of the workshop, click here. Today, we’ll take a look at one of the sessions led by Daniel Bristot de Oliveira, Principal Software Engineer at Red Hat, and Gabriele Paoloni, Senior Software Architect at Intel, titled “A Maintainable and Scalable Kernel Qualification Approach for Automotive.”

In this presentation, Daniel and Gabriele present an innovative approach that aims for the Functional Safety qualification of Linux by leveraging both ISO26262-6 and ISO26262-8.12.

The goal of this presentation was to get feedback on the approach suitability from a Functional Safety point of view, the approach usability in the current Linux mainline development flow and discuss about the next steps.

If you would like to learn more, Daniel and Gabriele will be giving an updated presentation at Embedded Linux Conference on September 28. Learn more about the session and other ELISA talks here.