Date   

Small student project idea on appropriate integration trees in MAINTAINERS

Lukas Bulwahn
 

Dear all,


here is a small student project idea:


In previous work on MAINTAINERS and process conformance, Pia Eichinger
[1] has investigated: are patches integrated by the maintainers
defined by the responsibilities in MAINTAINERS?

In this project, we are interested in a related (possibly simpler)
question: Are the commits integrated into the appropriate integration
trees referenced in MAINTAINERS?

As I believe, a main difference between considering maintainers and
integration trees is that the information in MAINTAINERS about
integration trees is more erroneous, as it is not used as prominently
as the personal maintainer information, name and email, with the
wide-spread use of ./scripts/get_maintainer.pl. So, correcting those
errors on integration trees in MAINTAINERS is more dominant (but also
simpler) compared to correcting errors on personal maintainer
information in MAINTAINERS.

The answer on the question above can then ultimately be used to
identify which integration tree entries should be added to specific
sections in MAINTAINERS to match best against the actual integration
observed in git.

The factors and metric to determine what is best is of course the
challenging task of identifying a suitable heuristics that is:
1. good enough to be used to create a change to MAINTAINERS that is
accepted by the community, and
2. simple enough to be implemented with reasonable effort.

Background:

The MAINTAINERS section includes references, through the T: entries,
to the location of a source configuration management (SCM) tree with
its type, e.g., git, quilt, hg,
For each commit, the kernel git history carries the commit's
integration tree path, i.e., the information through with source
configuration management (SCM) trees a commit was integrated until it
was finally integrated into Linus Torvalds' tree.

Ideally the references in the MAINTAINERS sections are:
- complete, i.e, all integration trees used for recent kernel
releases are mentioned in MAINTAINERS.
- sound, i.e., the majority of the commits are integrated through
the trees referenced in the MAINTAINERS sections a patch belongs to.
- precise, i.e., for each MAINTAINERS section, the majority of the
commits that belong to a section are integrated through the tree
referenced in that section.

Goal:

We identify and measure to these properties above, completeness,
soundness and precision.

Then, we use that information to determine which integration tree
entries should be added to which specific sections to maximally
increase the three properties.

To evaluate the adequacy of this method, we can obtain feedback from
the responsible kernel maintainers through proposing patches modifying
the MAINTAINERS file, for the additions that we identified as most
relevant (maximally increasing the properties, to a reasonable
threshold of number of patch proposals [to not swamp maintainers
initially] and a threshold on relevance [to not send out minor changes
that are largely irrelevant to the community]).

In this project, we can make use of:

- gitdm [git://git.lwn.net/gitdm.git]: gitdm includes some scripts to
parse MAINTAINERS and obtain the integration tree patch of a commit.

and/or

- pasta [https://github.com/lfd/PaStA]: Similarly to gitdm, pasta
provides functionality to parse MAINTAINERS and some functionalities
on extracting information on commits.

Potential project phases:

- In the first phase (PoC phase), we could probably just create a
setup that combines or extends the functionality in gitdm and/or in
pasta.

- In the second phase (MAINTAINERS patch creation phase), we send out
some patches and collect feedback from maintainers.

- In a third phase, with a better understanding of the individual
pieces in gitdm and/or in pasta, we could then create a cleaner design
that also refactors gitdm and pasta to share the same implementation
when essentially the same basic functionality is used within the
various analyses.


References:

[1] https://lists.elisa.tech/g/devel/message/1269


---

Any thoughts on this small student project?

If it is not too crazy, I will mentor a student on this project
through one of the next mentoring programs (Google Summer of Code, LF
mentorship, etc.).


Lukas


Google Summer of Code 2020 - Project ideas page for the Linux Foundation online

Lukas Bulwahn
 

Hi all,

Till Kamppeter is looking for project ideas for Google Summer of Code
2020; ideas from the ELISA Project can be discussed on the mailing
list and I would set up the project list idea page if there are any
interesting ideas and interested mentors.

---

Till wrote:

the Linux Foundation will apply again as mentoring organization in this
year's Google Summer of Code.

Note that GSoC 2021 will be different, the 3-months student projects
will be replaced by part-time projects, 6-weeks full-time-equivalent, to
be done in a 10-week time-window. Stipends are appropriately reduced to
the half amount, leading to the same per-hour value.

On January 29, 2021 the application period for mentoring organizations
for the Google Summer of Code 2021 will start.

To be successful, we need a rich project idea list so that we will get
selected by Google.

I have set up a page for project ideas for the Linux Foundation's
participation in the Google Summer of Code 2021:

https://wiki.linuxfoundation.org/gsoc/google-summer-code-2021

Please add your ideas to the sub-page of your work group. Also remove
project ideas which are already done in one of the previous years or not
needed any more and make sure that all contact info is up-to-date and
all links are working.

If you have problems mail me with your project ideas and other editing
wishes.

The ideas list is in the Linux Foundation Wiki. If you want to edit and
did not have the edit rights already from previous years, please tell me
and I give you edit rights. I need your Linux Foundation user name for
that and the e-mail address associated with this account for this.

Please also take into account that the deadline for our application as
mentoring organization is Feb 19 and after that Google will evaluate the
applications. So have your ideas (at least most of them, ideas can be
posted up to the student application deadline) in by then to raise our
chances to get accepted.

Please also tell us if you do not want to participate any more with your
workgroup, so that we can remove your sub-page.

---


Lukas


Re: REMINDER: [ELISA Technical Community] ELISA Workshop #6 Registration Now Thru January 28th

Min Yu
 


On Tue, Jan 19, 2021 at 7:57 AM Min Yu via lists.elisa.tech <myu=linuxfoundation.org@...> wrote:
Dear all,

Just a gentle reminder to register for the upcoming ELISA Workshop: https://www.surveymonkey.com/r/ELISA-Workshop-6-Registration

Please help us promote the Workshop in your network. More information about the Workshop can be found here: https://elisa.tech/workshop/2020/12/07/elisa-workshop-6-virtual-february-2-4/

Kind regards,
Min

--
Min Yu
Operations Manager
The Linux Foundation
+1(530) 902-6464 (m)

---------- Forwarded message ---------
From: Min Yu via lists.elisa.tech <myu=linuxfoundation.org@lists.elisa.tech>
Date: Mon, Jan 11, 2021 at 8:41 AM
Subject: [ELISA Technical Community] ELISA Workshop #6 Registration Now Thru January 28th
To: <devel@...>


Dear all,



We look forward to your participation.

Kind regards,
Min
--
Min Yu
Operations Manager
The Linux Foundation
+1(530) 902-6464 (m)


REMINDER: [ELISA Technical Community] ELISA Workshop #6 Registration Now Thru January 28th

Min Yu
 

Dear all,

Just a gentle reminder to register for the upcoming ELISA Workshop: https://www.surveymonkey.com/r/ELISA-Workshop-6-Registration

Please help us promote the Workshop in your network. More information about the Workshop can be found here: https://elisa.tech/workshop/2020/12/07/elisa-workshop-6-virtual-february-2-4/

Kind regards,
Min

--
Min Yu
Operations Manager
The Linux Foundation
+1(530) 902-6464 (m)

---------- Forwarded message ---------
From: Min Yu via lists.elisa.tech <myu=linuxfoundation.org@...>
Date: Mon, Jan 11, 2021 at 8:41 AM
Subject: [ELISA Technical Community] ELISA Workshop #6 Registration Now Thru January 28th
To: <devel@...>


Dear all,



We look forward to your participation.

Kind regards,
Min
--
Min Yu
Operations Manager
The Linux Foundation
+1(530) 902-6464 (m)


Re: RT Linux overview for ELISA

Corey Minyard
 

On Sat, Jan 16, 2021 at 08:48:42AM +0000, Paoloni, Gabriele wrote:

snip...


If you have a system that needed real-time response in the 10s or 100s of
microseconds, then yes, PREEMPT_RT is useful. But if those are required
responses to meet safety goals, then current argumentation will be
useless.

If you don't have those needs, why would you use RT? I can't imagine a
need like this that is not safety related. Maybe there is, though.

If you are just trying to reduce jitter on audio and video, I don't
know, maybe, but that's not really required any more with current
technology.
As we discussed yesterday in the automotive wg the telltale use case
shall pet a WD every 200msec.
200ms is not an issue for normal preempt (formerly preempt LL in the RT
patch). It's probably not an issue for no preempt, but that's hard to
say.

The first practical step is to patch the WD subsystem to use the msec
granularity and see if we can meet such requirement.
Assuming that we can meet the requirement without RT patchset, as
next step we are considering:
a) to possibly artificially shorten this time to make RT consideration
How far you can shorten this without RT depends on a lot of factors and
will vary a lot from situation to situation. On modern hardware a few
tens of milliseconds is probably ok, but I'd want to spend some time
measuring. It's also possible you run into issues with long preemption
times that will need to be debugged.

b) to load the system with NSR dummy workloads to see if the RT
patchset would help to prioritize system resources allocation for
RT workloads so that we can still meet availability requirements
of the safety function.
The RT setting in Linux does not prioritize system resources. That's
already standard at all preempt levels. It does three main things:

* It run interrupts in kernel threads.
* It makes most things that turn interrupts off into no-ops.
* It turns most spinlocks into PI mutexes.

Anything you see with "raw_" in the name dealing with locks or irqs
means that will be a real spinlock/irq operation even under RT. These
are mostly very low-level things like in the IRQ code or timer handing.

It also has a set of tools in the kernel for measuring latency.

The goal of RT is not to make Linux into a priority based preemptible
system. It's already that. The goal is to reduce worst-case latency to
as low a time as feasibly possible, at the expense of performance.
How low that time can be depends on a lot of factors. Achieving 10s of
microseconds is possible in some situations. But it takes careful
overall system design. No different than any other RT system.

-corey


As we discussed all of this in the wg we thought that it would be
good to have an intro mentorship session for RT Linux, hence
this email...

Gab


-corey


Lukas
---------------------------------------------------------------------
INTEL CORPORATION ITALIA S.p.A. con unico socio
Sede: Milanofiori Palazzo E 4
CAP 20094 Assago (MI)
Capitale Sociale Euro 104.000,00 interamente versato
Partita I.V.A. e Codice Fiscale 04236760155
Repertorio Economico Amministrativo n. 997124
Registro delle Imprese di Milano nr. 183983/5281/33
Soggetta ad attivita' di direzione e coordinamento di
INTEL CORPORATION, USA

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Re: RT Linux overview for ELISA

Paoloni, Gabriele
 

Hi Corey

-----Original Message-----
From: Corey Minyard <cminyard@mvista.com>
Sent: Friday, January 15, 2021 6:41 PM
To: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Cc: Paoloni, Gabriele <gabriele.paoloni@intel.com>; Shuah Khan
<skhan@linuxfoundation.org>; Kate Stewart
<kstewart@linuxfoundation.org>; devel@lists.elisa.tech;
automotive@lists.elisa.tech
Subject: Re: [ELISA Technical Community] RT Linux overview for ELISA

On Fri, Jan 15, 2021 at 04:23:35PM +0100, Lukas Bulwahn wrote:
On Fri, Jan 15, 2021 at 3:58 PM Corey Minyard <cminyard@mvista.com>
wrote:

On Fri, Jan 15, 2021 at 02:04:44PM +0000, Paoloni, Gabriele wrote:
Hi Shuah, Kate

Today in the Automotive WG we discussed about the possibility of
looking into the RT Patchset to support automotive use cases.

In doing so we realized that we would need mentorship on two aspects
of RT Linux:

1. Architectural Features developed by RT Linux:
* What's been done so far to propel RT capabilities
* What's been pushed into mainline and what is planned for the
futures (including planned timelines)
2. Development Process of RT Linux:
* What is the process to develop RT Patchsets?
* Is it similar to the one followed to get changes accepted into Linux
mainline?

Since we paid as Gold member can we get somebody from RT Linux to
mentor us? It maybe good to have a session in the next workshop maybe....

I'm sorry I missed the meeting, but I'm having a bunch of meetings that
I can't miss that are overlapping. That should be done in the next
couple of weeks.

What use cases drives the RT requirement? RT makes significant
behavioral changes to the kernel; from a safety point of view I would
avoid it if possible.
According to my interpretation, there is no requirement in the
automotive use case that requires PREEMPT_RT.
Then, IMHO, this is an unnecessary distraction. If you have a system
that needs that level of RT responsiveness, current safety arguments for
Linux are not going to work.
Pls see below



I don't think that the safety argumentation changes significantly, though.

If you have a proper argument for your claim without PREEMPT_RT, the
argument and claim works also with PREEMPT_RT.
I wasn't really talking from a safety claim point of view, just from an
overall safety point of view. In my experience, PREEMPT_RT tends to
uncover a lot of preemption bugs that are otherwise innocuous (which is
why we test mostly with PREEMPT_RT enabled). But...

If you have a system that needed real-time response in the 10s or 100s of
microseconds, then yes, PREEMPT_RT is useful. But if those are required
responses to meet safety goals, then current argumentation will be
useless.

If you don't have those needs, why would you use RT? I can't imagine a
need like this that is not safety related. Maybe there is, though.

If you are just trying to reduce jitter on audio and video, I don't
know, maybe, but that's not really required any more with current
technology.
As we discussed yesterday in the automotive wg the telltale use case
shall pet a WD every 200msec.
The first practical step is to patch the WD subsystem to use the msec
granularity and see if we can meet such requirement.
Assuming that we can meet the requirement without RT patchset, as
next step we are considering:
a) to possibly artificially shorten this time to make RT consideration
b) to load the system with NSR dummy workloads to see if the RT
patchset would help to prioritize system resources allocation for
RT workloads so that we can still meet availability requirements
of the safety function.

As we discussed all of this in the wg we thought that it would be
good to have an intro mentorship session for RT Linux, hence
this email...

Gab


-corey


Lukas
---------------------------------------------------------------------
INTEL CORPORATION ITALIA S.p.A. con unico socio
Sede: Milanofiori Palazzo E 4
CAP 20094 Assago (MI)
Capitale Sociale Euro 104.000,00 interamente versato
Partita I.V.A. e Codice Fiscale 04236760155
Repertorio Economico Amministrativo n. 997124
Registro delle Imprese di Milano nr. 183983/5281/33
Soggetta ad attivita' di direzione e coordinamento di
INTEL CORPORATION, USA

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Re: RT Linux overview for ELISA

Corey Minyard
 

On Fri, Jan 15, 2021 at 04:23:35PM +0100, Lukas Bulwahn wrote:
On Fri, Jan 15, 2021 at 3:58 PM Corey Minyard <cminyard@mvista.com> wrote:

On Fri, Jan 15, 2021 at 02:04:44PM +0000, Paoloni, Gabriele wrote:
Hi Shuah, Kate

Today in the Automotive WG we discussed about the possibility of looking into the RT Patchset to support automotive use cases.

In doing so we realized that we would need mentorship on two aspects of RT Linux:

1. Architectural Features developed by RT Linux:
* What's been done so far to propel RT capabilities
* What's been pushed into mainline and what is planned for the futures (including planned timelines)
2. Development Process of RT Linux:
* What is the process to develop RT Patchsets?
* Is it similar to the one followed to get changes accepted into Linux mainline?

Since we paid as Gold member can we get somebody from RT Linux to mentor us? It maybe good to have a session in the next workshop maybe....
I'm sorry I missed the meeting, but I'm having a bunch of meetings that
I can't miss that are overlapping. That should be done in the next
couple of weeks.

What use cases drives the RT requirement? RT makes significant
behavioral changes to the kernel; from a safety point of view I would
avoid it if possible.
According to my interpretation, there is no requirement in the
automotive use case that requires PREEMPT_RT.
Then, IMHO, this is an unnecessary distraction. If you have a system
that needs that level of RT responsiveness, current safety arguments for
Linux are not going to work.


I don't think that the safety argumentation changes significantly, though.

If you have a proper argument for your claim without PREEMPT_RT, the
argument and claim works also with PREEMPT_RT.
I wasn't really talking from a safety claim point of view, just from an
overall safety point of view. In my experience, PREEMPT_RT tends to
uncover a lot of preemption bugs that are otherwise innocuous (which is
why we test mostly with PREEMPT_RT enabled). But...

If you have a system that needed real-time response in the 10s or 100s of
microseconds, then yes, PREEMPT_RT is useful. But if those are required
responses to meet safety goals, then current argumentation will be
useless.

If you don't have those needs, why would you use RT? I can't imagine a
need like this that is not safety related. Maybe there is, though.

If you are just trying to reduce jitter on audio and video, I don't
know, maybe, but that's not really required any more with current
technology.

-corey


Lukas


Re: [ELISA Automotive WG] [ELISA Technical Community] RT Linux overview for ELISA

Paoloni, Gabriele
 

Hi Lukas

-----Original Message-----
From: automotive@lists.elisa.tech <automotive@lists.elisa.tech> On Behalf
Of Lukas Bulwahn
Sent: Friday, January 15, 2021 4:24 PM
To: Corey Minyard <cminyard@mvista.com>
Cc: Paoloni, Gabriele <gabriele.paoloni@intel.com>; Shuah Khan
<skhan@linuxfoundation.org>; Kate Stewart
<kstewart@linuxfoundation.org>; devel@lists.elisa.tech;
automotive@lists.elisa.tech
Subject: Re: [ELISA Automotive WG] [ELISA Technical Community] RT Linux
overview for ELISA

On Fri, Jan 15, 2021 at 3:58 PM Corey Minyard <cminyard@mvista.com>
wrote:

On Fri, Jan 15, 2021 at 02:04:44PM +0000, Paoloni, Gabriele wrote:
Hi Shuah, Kate

Today in the Automotive WG we discussed about the possibility of
looking into the RT Patchset to support automotive use cases.

In doing so we realized that we would need mentorship on two aspects
of RT Linux:

1. Architectural Features developed by RT Linux:
* What's been done so far to propel RT capabilities
* What's been pushed into mainline and what is planned for the
futures (including planned timelines)
2. Development Process of RT Linux:
* What is the process to develop RT Patchsets?
* Is it similar to the one followed to get changes accepted into Linux
mainline?

Since we paid as Gold member can we get somebody from RT Linux to
mentor us? It maybe good to have a session in the next workshop maybe....

I'm sorry I missed the meeting, but I'm having a bunch of meetings that
I can't miss that are overlapping. That should be done in the next
couple of weeks.

What use cases drives the RT requirement? RT makes significant
behavioral changes to the kernel; from a safety point of view I would
avoid it if possible.
According to my interpretation, there is no requirement in the
automotive use case that requires PREEMPT_RT.
So far we don't have a requirement to use PREEMPT_RT in the telltale use case
however we recognize that in future we may leverage the RT Patchset.

So the idea is to start evaluating it in view of future use case, hence I sent
this email.

Thanks
Gab


I don't think that the safety argumentation changes significantly, though.

If you have a proper argument for your claim without PREEMPT_RT, the
argument and claim works also with PREEMPT_RT.

Lukas



---------------------------------------------------------------------
INTEL CORPORATION ITALIA S.p.A. con unico socio
Sede: Milanofiori Palazzo E 4
CAP 20094 Assago (MI)
Capitale Sociale Euro 104.000,00 interamente versato
Partita I.V.A. e Codice Fiscale 04236760155
Repertorio Economico Amministrativo n. 997124
Registro delle Imprese di Milano nr. 183983/5281/33
Soggetta ad attivita' di direzione e coordinamento di
INTEL CORPORATION, USA

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Re: RT Linux overview for ELISA

Lukas Bulwahn
 

On Fri, Jan 15, 2021 at 3:58 PM Corey Minyard <cminyard@mvista.com> wrote:

On Fri, Jan 15, 2021 at 02:04:44PM +0000, Paoloni, Gabriele wrote:
Hi Shuah, Kate

Today in the Automotive WG we discussed about the possibility of looking into the RT Patchset to support automotive use cases.

In doing so we realized that we would need mentorship on two aspects of RT Linux:

1. Architectural Features developed by RT Linux:
* What's been done so far to propel RT capabilities
* What's been pushed into mainline and what is planned for the futures (including planned timelines)
2. Development Process of RT Linux:
* What is the process to develop RT Patchsets?
* Is it similar to the one followed to get changes accepted into Linux mainline?

Since we paid as Gold member can we get somebody from RT Linux to mentor us? It maybe good to have a session in the next workshop maybe....
I'm sorry I missed the meeting, but I'm having a bunch of meetings that
I can't miss that are overlapping. That should be done in the next
couple of weeks.

What use cases drives the RT requirement? RT makes significant
behavioral changes to the kernel; from a safety point of view I would
avoid it if possible.
According to my interpretation, there is no requirement in the
automotive use case that requires PREEMPT_RT.

I don't think that the safety argumentation changes significantly, though.

If you have a proper argument for your claim without PREEMPT_RT, the
argument and claim works also with PREEMPT_RT.

Lukas


Re: RT Linux overview for ELISA

Corey Minyard
 

On Fri, Jan 15, 2021 at 02:04:44PM +0000, Paoloni, Gabriele wrote:
Hi Shuah, Kate

Today in the Automotive WG we discussed about the possibility of looking into the RT Patchset to support automotive use cases.

In doing so we realized that we would need mentorship on two aspects of RT Linux:

1. Architectural Features developed by RT Linux:
* What's been done so far to propel RT capabilities
* What's been pushed into mainline and what is planned for the futures (including planned timelines)
2. Development Process of RT Linux:
* What is the process to develop RT Patchsets?
* Is it similar to the one followed to get changes accepted into Linux mainline?

Since we paid as Gold member can we get somebody from RT Linux to mentor us? It maybe good to have a session in the next workshop maybe....
I'm sorry I missed the meeting, but I'm having a bunch of meetings that
I can't miss that are overlapping. That should be done in the next
couple of weeks.

What use cases drives the RT requirement? RT makes significant
behavioral changes to the kernel; from a safety point of view I would
avoid it if possible.

If no one from RT Linux can help, I've done quite a bit of work with
linux-rt in the past. MontaVista has distributed it for a very long
time, we do about 90% of our testing on it, I've chased down bugs, and
we have customers using it. It's been a while since I've been active on
it, but I don't think the basics have changed.

-corey


Thanks
Gab




---------------------------------------------------------------------
INTEL CORPORATION ITALIA S.p.A. con unico socio
Sede: Milanofiori Palazzo E 4
CAP 20094 Assago (MI)
Capitale Sociale Euro 104.000,00 interamente versato
Partita I.V.A. e Codice Fiscale 04236760155
Repertorio Economico Amministrativo n. 997124
Registro delle Imprese di Milano nr. 183983/5281/33
Soggetta ad attivita' di direzione e coordinamento di
INTEL CORPORATION, USA

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.





Re: [ELISA Automotive WG] RT Linux overview for ELISA

Lukas Bulwahn
 

On Fri, Jan 15, 2021 at 3:05 PM Paoloni, Gabriele
<gabriele.paoloni@intel.com> wrote:

Hi Shuah, Kate



Today in the Automotive WG we discussed about the possibility of looking into the RT Patchset to support automotive use cases.



In doing so we realized that we would need mentorship on two aspects of RT Linux:

Architectural Features developed by RT Linux:

What’s been done so far to propel RT capabilities
The wiki here provides you the entry point:

https://wiki.linuxfoundation.org/realtime/start

What’s been pushed into mainline and what is planned for the futures (including planned timelines)
You will find some articles on features motivated by real-time support
at LWN.net.

In the future, it is planned to submit and merge the remaining changes
that are sketched in this branch:

https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/log/?h=linux-5.10.y-rt-rebase

Just some key feature: migrate_disable, kmap_atomic, printk (aka the
neverending blocker), softirq, rtmutex, and I think then you are
basically done...

Development Process of RT Linux:

What is the process to develop RT Patchsets?
Is it similar to the one followed to get changes accepted into Linux mainline?
It is the same process, but I think contributions should focus on
testing and describing relevant use cases that shall meet certain
timing requirements.

So far, most (if not all) attention has been simply on making the
identification of the need and execution of the context switch from
one application to another maximal deterministic.

I think you can find a number of talks on Real-time on the internet
due to the many recorded conferences and workshops in the past.


Lukas


RT Linux overview for ELISA

Paoloni, Gabriele
 

Hi Shuah, Kate

 

Today in the Automotive WG we discussed about the possibility of looking into the RT Patchset to support automotive use cases.

 

In doing so we realized that we would need mentorship on two aspects of RT Linux:

  1. Architectural Features developed by RT Linux:
    1. What’s been done so far to propel RT capabilities
    2. What’s been pushed into mainline and what is planned for the futures (including planned timelines)
  2. Development Process of RT Linux:
    1. What is the process to develop RT Patchsets?
    2. Is it similar to the one followed to get changes accepted into Linux mainline?

 

Since we paid as Gold member can we get somebody from  RT Linux to mentor us? It maybe good to have a session in the next workshop maybe….

 

Thanks

Gab

 

 

 

---------------------------------------------------------------------
INTEL CORPORATION ITALIA S.p.A. con unico socio
Sede: Milanofiori Palazzo E 4
CAP 20094 Assago (MI)
Capitale Sociale Euro 104.000,00 interamente versato
Partita I.V.A. e Codice Fiscale  04236760155
Repertorio Economico Amministrativo n. 997124
Registro delle Imprese di Milano nr. 183983/5281/33
Soggetta ad attivita' di direzione e coordinamento di
INTEL CORPORATION, USA

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Re: Technical Strategy

Shuah Khan
 

Hi John,

Thanks you this detailed email with suggestions to improve
strategy definition. This document is shared with all.

Will you be able to access the document and make suggested
edits? This would work the best.

thanks,
-- Shuah

On 1/13/21 10:14 AM, John MacGregor wrote:
Hi Shuah,
TLDR:
The technical strategy document discussions mix the desired outcomes, with the primary and subordinate goals of the various ELISA activities and that makes it unnecessarily hard to achieve a consensus.  It would be better to formulate a hierarchy of strategies.
For a couple of meetings now, I've considered bringing my comments to the technical strategy document into the synch meetings.  But considering that they are more at the "meta"-level, I just haven't found or used the right moment.
One problem I have is that I tend to run on with my explanations.
Anther problem I that I fundamentally agree with what everybody is saying, I just see it in a perhaps more refined context.  It would probably make my comments seem a little distracting.
In the last meeting (before Christmas), Pete said something along the lines that it's typical that people talk around each other because they haven't achieved a common understanding.  I hope this e-mail brings us a little bit further to a common understanding of what the technical strategy could be.
Right now, I'll just present the notes I made for the telco. If we find they have merit, I can explain them in more detail.
STRATEGIES
- First, a personal definition: A strategy is a set of activities or steps to reach a desired state or outcome (or a goal, the usual term, but one that I will avoid in order to not confuse it with the goals in the strategy document)
- A strategy has only one "desired outcome", a concrete state of something (I think)
    - There may be a number of aspects of the outcome (or parameters, perhaps) which differentiate the optimality of the strategy.  These might also be considered goals...
- There may be alternative strategies for reaching the "desired outcome"
- Strategies are recursive
    - each step or activity in the strategy has its own desired outcome, which may imply further sub-strategies
    - whatever it may be, THE TECHNICAL ELISA STRATEGY should have only _one_ desired outcome and will have a number of steps or activities that are directed at achieving this desired outcome.
DESIRED OUTCOME
- Elana has suggested that the technical strategy should be aligned with the mission statement (e-mail on 12 December)
    - The project name, the mission described on the home page of the project website and the mission in the charter are slightly different
    - There is a difference between "making it easier" (doesn't mean that the desired outcome is possible) and "enabling" (implies that the desired outcome is possible)
    - There is a difference between "defining and maintaining a set of elements" (no purpose, no target user) and "companies building and certifying"
- Note that this is a _technical_ strategy
CURRENT DOCUMENT
- the "goals" listed in the document are actually activities...  (I know, I suggested that they were goals... but, hey, I'm human after all.)
- The technical strategy proposed by Gab might be too tailored to ISO 26262 (and/or implicitly IEC 61508) and qualification
    - at least it may neglect the possibility of enhancing the standards to accommodate open source
    - there's nothing wrong with considering it as being a sensible first step
- @Gab: note that you haven't documented / defined (in detail) the desired outcome of the activities you've defined.
- note that whatever the desired ELISA outcome may be, there may be alternative strategies to reach it.
- "formalities"
    - no problem statement, diagnosis
    - traceability between goals and activities, between activities and sub-activities (although this may be overkill)
- note that we don't have to have a strategy to achieve the ultimate ELISA outcome, we could have a strategy to make the first sensible step.
Cheers
John
P.S. I believe in having a primary author that controls the content of a document.  If anybody (probably just Gab and Shuah) wants, I'm perfectly willing to offer alternative formulations or to contribute new content to the document.


Technical Strategy

John MacGregor
 

Hi Shuah,

TLDR:
The technical strategy document discussions mix the desired outcomes, with the primary and subordinate goals of the various ELISA activities and that makes it unnecessarily hard to achieve a consensus. It would be better to formulate a hierarchy of strategies.

For a couple of meetings now, I've considered bringing my comments to the technical strategy document into the synch meetings. But considering that they are more at the "meta"-level, I just haven't found or used the right moment.

One problem I have is that I tend to run on with my explanations.

Anther problem I that I fundamentally agree with what everybody is saying, I just see it in a perhaps more refined context. It would probably make my comments seem a little distracting.

In the last meeting (before Christmas), Pete said something along the lines that it's typical that people talk around each other because they haven't achieved a common understanding. I hope this e-mail brings us a little bit further to a common understanding of what the technical strategy could be.

Right now, I'll just present the notes I made for the telco. If we find they have merit, I can explain them in more detail.

STRATEGIES
- First, a personal definition: A strategy is a set of activities or steps to reach a desired state or outcome (or a goal, the usual term, but one that I will avoid in order to not confuse it with the goals in the strategy document)
- A strategy has only one "desired outcome", a concrete state of something (I think)
- There may be a number of aspects of the outcome (or parameters, perhaps) which differentiate the optimality of the strategy. These might also be considered goals...
- There may be alternative strategies for reaching the "desired outcome"
- Strategies are recursive
- each step or activity in the strategy has its own desired outcome, which may imply further sub-strategies
- whatever it may be, THE TECHNICAL ELISA STRATEGY should have only _one_ desired outcome and will have a number of steps or activities that are directed at achieving this desired outcome.

DESIRED OUTCOME
- Elana has suggested that the technical strategy should be aligned with the mission statement (e-mail on 12 December)
- The project name, the mission described on the home page of the project website and the mission in the charter are slightly different
- There is a difference between "making it easier" (doesn't mean that the desired outcome is possible) and "enabling" (implies that the desired outcome is possible)
- There is a difference between "defining and maintaining a set of elements" (no purpose, no target user) and "companies building and certifying"
- Note that this is a _technical_ strategy

CURRENT DOCUMENT
- the "goals" listed in the document are actually activities... (I know, I suggested that they were goals... but, hey, I'm human after all.)
- The technical strategy proposed by Gab might be too tailored to ISO 26262 (and/or implicitly IEC 61508) and qualification
- at least it may neglect the possibility of enhancing the standards to accommodate open source
- there's nothing wrong with considering it as being a sensible first step
- @Gab: note that you haven't documented / defined (in detail) the desired outcome of the activities you've defined.
- note that whatever the desired ELISA outcome may be, there may be alternative strategies to reach it.
- "formalities"
- no problem statement, diagnosis
- traceability between goals and activities, between activities and sub-activities (although this may be overkill)
- note that we don't have to have a strategy to achieve the ultimate ELISA outcome, we could have a strategy to make the first sensible step.

Cheers

John

P.S. I believe in having a primary author that controls the content of a document. If anybody (probably just Gab and Shuah) wants, I'm perfectly willing to offer alternative formulations or to contribute new content to the document.


Re: TSC Meeting agenda (Org focus) - Wed, 12/2/2020

John MacGregor
 

+1

I could quibble... but basically I agree wholeheartedly.

On 02/12/2020 13:26, elana.copperman@mobileye.com wrote:
Thanks to all.
We need to be sure our strategy is aligned with ELISA's mission statement, which is to make it *easier* for companies to build and certify Linux-based systems for safety critical applications.
Our strategy should be focused on a process which is scalable and maintainable in complex real-life systems.
See you all soon for a good discussion.
Regards
Elana
------------------------------------------------------------------------
*From:* devel@lists.elisa.tech <devel@lists.elisa.tech> on behalf of Paoloni, Gabriele <gabriele.paoloni@intel.com>
*Sent:* Wednesday, December 2, 2020 2:02 PM
*To:* Shuah Khan <skhan@linuxfoundation.org>; devel@lists.elisa.tech <devel@lists.elisa.tech>
*Subject:* Re: [ELISA Technical Community] TSC Meeting agenda (Org focus) - Wed, 12/2/2020
[...]

Yes please add them as suggested edits.

Thanks Paul for starting the thread.

https://docs.google.com/document/d/1Jx77Mw_BqdanGYILCkyw3Fdifxn7F
<https://docs.google.com/document/d/1Jx77Mw_BqdanGYILCkyw3Fdifxn7F>;
O7Dmt-9ZU2KISo/edit#
Do you want us to comment/modify the file before tomorrow's meeting
or you want us to go over it altogether tomorrow?
Please do suggested edits for changes. One more thing that need
to be outlined is how WGs fit in these goals and interactions
between WGs for goals. The idead being the graphic will be goal
driven with WGs feeding into these goals.
Hi Shuah and all
I tried to elaborate better but I cannot make suggested edits due to lack of permission.
So I just copied the file and modified locally; attaching it here for discussion.
I deliberately didn't allocate tasks to WGs as to leave it for discussion; instead I focused on the qualification flow.
Thanks
Gab
After our meeting, I will try to put a visual for this doc.
thanks,
-- Shuah
---------------------------------------------------------------------
INTEL CORPORATION ITALIA S.p.A. con unico socio
Sede: Milanofiori Palazzo E 4
CAP 20094 Assago (MI)
Capitale Sociale Euro 104.000,00 interamente versato
Partita I.V.A. e Codice Fiscale  04236760155
Repertorio Economico Amministrativo n. 997124
Registro delle Imprese di Milano nr. 183983/5281/33
Soggetta ad attivita' di direzione e coordinamento di
INTEL CORPORATION, USA
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Re: State of the Safety Architecture WG

elana.copperman@...
 

On behalf of the Development Process WG, since the last update:

  • We have completed the analysis of gaps in current kernel test process (based on safety standards).
  • We have identified specific tasks for follow up by this WG or by other WGs.

 

Next step is the workshop, in which we have a dedicated session with the goal:

  • To prioritize and assign those specific tasks.
  • To review the 2 work products (Kernel test process analysis, and the reference spreadsheet), merge the relevant sections, and identify any remaining gaps.
  • To evaluate the value of this particular work product, and in general make a decision if extending this effort to further analysis is of value to either the safety community or the Linux kernel community.

 

 

From: devel@... <devel@...> On Behalf Of Paoloni, Gabriele
Sent: Wednesday, January 13, 2021 10:44 AM
To: devel@...
Subject: [ELISA Technical Community] State of the Safety Architecture WG

 

Hi All

 

Since the last update:

  • We started looking at the Telltale use case from the automotive WG discussing about key challenges and expectation from the Kernel
  • We analyzed the Safety Concept and we allocated the TSRs and FSRs to code sections of the safety applications

 

Very Next Steps:

  • Based on TSRs and FSRs we need to define and allocate safety requirements to Kernel subsystems
  • Based on such Safety Requirements we need to draft a Safety Analysis

 

Gab

---------------------------------------------------------------------
INTEL CORPORATION ITALIA S.p.A. con unico socio
Sede: Milanofiori Palazzo E 4
CAP 20094 Assago (MI)
Capitale Sociale Euro 104.000,00 interamente versato
Partita I.V.A. e Codice Fiscale  04236760155
Repertorio Economico Amministrativo n. 997124
Registro delle Imprese di Milano nr. 183983/5281/33
Soggetta ad attivita' di direzione e coordinamento di
INTEL CORPORATION, USA

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


State of the Safety Architecture WG

Paoloni, Gabriele
 

Hi All

 

Since the last update:

  • We started looking at the Telltale use case from the automotive WG discussing about key challenges and expectation from the Kernel
  • We analyzed the Safety Concept and we allocated the TSRs and FSRs to code sections of the safety applications

 

Very Next Steps:

  • Based on TSRs and FSRs we need to define and allocate safety requirements to Kernel subsystems
  • Based on such Safety Requirements we need to draft a Safety Analysis

 

Gab

---------------------------------------------------------------------
INTEL CORPORATION ITALIA S.p.A. con unico socio
Sede: Milanofiori Palazzo E 4
CAP 20094 Assago (MI)
Capitale Sociale Euro 104.000,00 interamente versato
Partita I.V.A. e Codice Fiscale  04236760155
Repertorio Economico Amministrativo n. 997124
Registro delle Imprese di Milano nr. 183983/5281/33
Soggetta ad attivita' di direzione e coordinamento di
INTEL CORPORATION, USA

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Workgroup update - Automotive

Jochen Kall
 

Hi everyone,

in preparation of todays workgroup update centered TSC meeting, here a quick overview of our activities since the last update:

- Finished meta-elisa repo restructuring
- Cluster Demo use case
- Concept Side
- Activity Diagrams
- Safety Analysis
- Implementation Side
- Added CAN support to properly remote control the QT Application
- Integrated the watchdog subsystem
- Implemented a terminal based control panel for easy control/triggering of faults
- First transfer of requirements to the Architecture WG for analysis
- Currently working on
- Transition to markdown documents
- Consolidation of documents in general
- Planning for the next Quarter

Best regards
Jochen

On behalf of Toyota. 
--
Dr. rer. nat. Jochen Kall
Functional Safety
 
ITK Engineering GmbH
Im Speyerer Tal 6
76761 Rülzheim
  
mailto:jochen.kall@itk-engineering.de
 ______________________________________________________________
 
ITK Engineering GmbH | Im Speyerer Tal 6 | 76761 Rülzheim
Tel.: +49 7272 7703-0 | Fax: +49 7272 7703-100
mailto:info@itk-engineering.de | http://www.itk-engineering.de/

Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board:
Dr. Rudolf Maier
Geschäftsführung/Executive Board:
Michael Englert (Vorsitzender/Chairman), Bernd Gohlicke
Sitz der Gesellschaft/Registered Office: 76761 Rülzheim
Registergericht/Registered Court: Amtsgericht Landau, HRB 32046
USt.-ID-Nr./VAT-ID-No. DE 813165046





--
Mit freundlichen Grüßen
Jochen Kall

--
Dr. rer. nat. Jochen Kall

Funktionale Sicherheit

ITK Engineering GmbH
Im Speyerer Tal 6
76761 Rülzheim

Tel.: +49 7272 7703-546
Fax: +49 7272 7703-100

Mobil:+491734957776

mailto:jochen.kall@itk-engineering.de ( jochen.kall@itk-engineering.de )

______________________________________________________________

ITK Engineering GmbH | Im Speyerer Tal 6 | 76761 Rülzheim

Tel.: +49 7272 7703-0 | Fax: +49 7272 7703-100

mailto:info@itk-engineering.de ( info@itk-engineering.de ) | http://www.itk-engineering.de ( http://www.itk-engineering.de/ )

Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board:

Dr. Rudolf Maier

Geschäftsführung/Executive Board:

Michael Englert (Vorsitzender/Chairman), Bernd Gohlicke

Sitz der Gesellschaft/Registered Office: 76761 Rülzheim

Registergericht/Registered Court: Amtsgericht Landau, HRB 32046

USt.-ID-Nr./VAT-ID-No. DE 813165046


Re: State of Tooling and Code Improvement Subgroup

Paoloni, Gabriele
 

Hi Lukas

-----Original Message-----
From: devel@lists.elisa.tech <devel@lists.elisa.tech> On Behalf Of Lukas
Bulwahn
Sent: Tuesday, January 12, 2021 6:46 PM
To: devel@lists.elisa.tech
Subject: [ELISA Technical Community] State of Tooling and Code
Improvement Subgroup

Roberto's ECLAIR Report:
- Access available upon request.
- Detailed investigation can be continued by volunteers. So far, some
limited interest.

Continuous Tool Invocations (Sudip's CI):
- Blocked by the lack of computing resources.

Setup of CodeChecker:
- Blocked by the lack of a project web server.

Eli’s Klokwork results:
- Export from Klokwork available.
- Triage not possible due to lack of detailed report.

Patch contributions:
- Group supports newcomers to patch contributions.

Summary:
- The group agrees that it is really unfortunate not to have any
proper infrastructure (compute and web servers) yet.
In the last governing board the budget was approved to go ahead with
the server rental. Also Shuah suggested the OSUOSL Hosting service
as possible option.
So I wonder if there has been any engagement and what is happening...

Maybe we can discuss this point today.

Gab

- We are happy to educate new members on how to create their first
patches.



---------------------------------------------------------------------
INTEL CORPORATION ITALIA S.p.A. con unico socio
Sede: Milanofiori Palazzo E 4
CAP 20094 Assago (MI)
Capitale Sociale Euro 104.000,00 interamente versato
Partita I.V.A. e Codice Fiscale 04236760155
Repertorio Economico Amministrativo n. 997124
Registro delle Imprese di Milano nr. 183983/5281/33
Soggetta ad attivita' di direzione e coordinamento di
INTEL CORPORATION, USA

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


State of Tooling and Code Improvement Subgroup

Lukas Bulwahn
 

Roberto's ECLAIR Report:
- Access available upon request.
- Detailed investigation can be continued by volunteers. So far, some
limited interest.

Continuous Tool Invocations (Sudip's CI):
- Blocked by the lack of computing resources.

Setup of CodeChecker:
- Blocked by the lack of a project web server.

Eli’s Klokwork results:
- Export from Klokwork available.
- Triage not possible due to lack of detailed report.

Patch contributions:
- Group supports newcomers to patch contributions.

Summary:
- The group agrees that it is really unfortunate not to have any
proper infrastructure (compute and web servers) yet.
- We are happy to educate new members on how to create their first patches.

1 - 20 of 1366