|
Small student project idea on appropriate integration trees in MAINTAINERS
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
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:
|
|||
|
|
|||
|
REMINDER: [ELISA Technical Community] ELISA Workshop #6 Registration Now Thru January 28th
Min Yu
|
|||
|
|
|||
|
Re: RT Linux overview for ELISA
Corey Minyard
On Sat, Jan 16, 2021 at 08:48:42AM +0000, Paoloni, Gabriele wrote:
snip... 200ms is not an issue for normal preempt (formerly preempt LL in the RTAs we discussed yesterday in the automotive wg the telltale use case 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 msecHow 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 RTThe 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
|
|||
|
|
|||
|
Re: RT Linux overview for ELISA
Paoloni, Gabriele
Hi Corey
toggle quoted messageShow quoted text
-----Original Message-----Pls see below As we discussed yesterday in the automotive wg the telltale use caseI wasn't really talking from a safety claim point of view, just from an 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 --------------------------------------------------------------------- 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:Then, IMHO, this is an unnecessary distraction. If you have a systemAccording to my interpretation, there is no requirement in the that needs that level of RT responsiveness, current safety arguments for Linux are not going to work. 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
|
|||
|
|
|||
|
Re: [ELISA Automotive WG] [ELISA Technical Community] RT Linux overview for ELISA
Paoloni, Gabriele
Hi Lukas
toggle quoted messageShow quoted text
-----Original Message-----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 --------------------------------------------------------------------- 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
On Fri, Jan 15, 2021 at 3:58 PM Corey Minyard <cminyard@mvista.com> wrote:
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, KateI'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
|
|||
|
|
|||
|
Re: [ELISA Automotive WG] RT Linux overview for ELISA
On Fri, Jan 15, 2021 at 3:05 PM Paoloni, Gabriele
<gabriele.paoloni@intel.com> wrote: 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: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:
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
--------------------------------------------------------------------- This e-mail and any attachments may contain confidential material for
|
|||
|
|
|||
|
Re: Technical Strategy
Shuah Khan
Hi John,
toggle quoted messageShow quoted text
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,
|
|||
|
|
|||
|
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
toggle quoted messageShow quoted text
I could quibble... but basically I agree wholeheartedly.
On 02/12/2020 13:26, elana.copperman@mobileye.com wrote:
Thanks to all.
|
|||
|
|
|||
|
Re: State of the Safety Architecture WG
elana.copperman@...
On behalf of the Development Process WG, since the last update:
Next step is the workshop, in which we have a dedicated session with the goal:
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:
Very Next Steps:
Gab --------------------------------------------------------------------- This e-mail and any attachments may contain confidential material for
|
|||
|
|
|||
|
State of the Safety Architecture WG
Paoloni, Gabriele
Hi All
Since the last update:
Very Next Steps:
Gab --------------------------------------------------------------------- This e-mail and any attachments may contain confidential material for
|
|||
|
|
|||
|
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
toggle quoted messageShow quoted text
-----Original Message-----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--------------------------------------------------------------------- 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
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.
|
|||
|
|
