Interference analysis and generic safety requirements template for an ARM64 Linuxsystem

[igor-stoppa]

Initial pdf documents

[reiterative]

Thanks very much for sharing these, Igor! To get them merged and available to a wider audience ASAP, I am going to propose that we don't review the content yet, but instead plan to add AsciiDoc conversions of the source material for each document in a future PR, so that we can propose and review future refinements and extensions.

To get this PR merged, I would like to see the following changes:

• Add a README.md in the folder with the existing documents, briefly explaining what they are, where they originate and how we intend to build upon them
• Change the name of the folder containing them to something like 'Contributions' and add links to it (and perhaps to the individual files) in the top-level README.md

I'm happy to help with all of this, and I will need to fix the problem with the CI first, as it is blocking merge.

[igor-stoppa]

To get this PR merged, I would like to see the following changes:

• Add a README.md in the folder with the existing documents, briefly explaining what they are, where they originate and how we intend to build upon them

Done, with a caveat: I have left out the intended use, I would prefer to add that part together with the markdown. I think the documents can be anyway justified as 3rd party contribution without peer-review.

• Change the name of the folder containing them to something like 'Contributions' and add links to it (and perhaps to the individual files) in the top-level README.md

Done.

[igor-stoppa]

I've added to the README that the files are 3rd party, that should make it even more evident that they are not peer-reviewed within ELISA

[igor-stoppa]

@reiterative it looks like the CI doesn't like the fact that I've used my work email in the Signed-off-by, even if it is registered as secondary email in this account.

Anyways, this is it. If you do not see any error I might have missed, please accept the pull request.

[bulwahn]

@reiterative it looks like the CI doesn't like the fact that I've used my work email in the Signed-off-by, even if it is registered as secondary email in this account.

The DCO check complains that the author and signed-off-by email addresses differ. If you look at https://github.com/elisa-tech/wg-osep/commit/a733820b2fefa3052d6451fb62e30e5c8c611c31.patch, you will see the author is with the gmail address and sign off is with the nvidia address. Decide for one of the two and then keep it consistent. From a legal point of view, there is no difference. The DCO check also does not rely on github knowing to that they might be aliases for the same person.

That should be easy to fix.

Anyways, this is it. If you do not see any error I might have missed, please accept the pull request.

[igor-stoppa]

@reiterative it looks like the CI doesn't like the fact that I've used my work email in the Signed-off-by, even if it is registered as secondary email in this account.

The DCO check complains that the author and signed-off-by email addresses differ. If you look at https://github.com/elisa-tech/wg-osep/commit/a733820b2fefa3052d6451fb62e30e5c8c611c31.patch, you will see the author is with the gmail address and sign off is with the nvidia address. Decide for one of the two and then keep it consistent. From a legal point of view, there is no difference. The DCO check also does not rely on github knowing to that they might be aliases for the same person.

That should be easy to fix.

@bulwahn I had understood the "error". What I am saying is that it's an error based on an assumption that I think is not correct and instead it should rather be a warning.

[bulwahn]

@reiterative it looks like the CI doesn't like the fact that I've used my work email in the Signed-off-by, even if it is registered as secondary email in this account.

The DCO check complains that the author and signed-off-by email addresses differ. If you look at https://github.com/elisa-tech/wg-osep/commit/a733820b2fefa3052d6451fb62e30e5c8c611c31.patch, you will see the author is with the gmail address and sign off is with the nvidia address. Decide for one of the two and then keep it consistent. From a legal point of view, there is no difference. The DCO check also does not rely on github knowing to that they might be aliases for the same person.
That should be easy to fix.

@bulwahn I had understood the "error". What I am saying is that it's an error based on an assumption that I think is not correct and instead it should rather be a warning.

Okay, but why is it important to you that the author email is with gmail and the signed-off-by is with nvidia? Maybe there are better ways to achieve your intentions of the two email addresses differently. In the end, it is not clear how someone else would use this git metadata and if that then really achieves the intent you have.

[igor-stoppa]

@bulwahn

Okay, but why is it important to you that the author email is with gmail and the signed-off-by is with nvidia? Maybe there are better ways to achieve your intentions of the two email addresses differently. In the end, it is not clear how someone else would use this git metadata and if that then really achieves the intent you have.

it is important to perform correct attribution, because it is fair to make it traceable in statistics, who sponsored the work - you can argue on the importance of this, but it's a fact that the sponsor is more obvious, in this way

it is convenient to me to use this git account and email address. because it is what I regularly use, and also for tracking purposes it rules out any possibility of me accidentally leaking private information, since this work is done from outside the company firewall and vpn

Notice also that I am not arguing on this check being in place, I'm just saying, if it helps having the warning, great. Now that it's confirmed there is no impersonation, please disregard the warning and merge the pull request, if there are no outstanding issues.

Besides, AFAIK, the email address used to deliver the requests gets discarded.
And you stated yourself that they are equally valid, legally.
I do not see the need to enforce unnecessary constraints.

[reiterative]

I think I understand your reasoning, Igor, and I do not see a problem in this case. I have set the DCO check to pass, and will now finish reading the documents.

[bulwahn]

@bulwahn

Okay, but why is it important to you that the author email is with gmail and the signed-off-by is with nvidia? Maybe there are better ways to achieve your intentions of the two email addresses differently. In the end, it is not clear how someone else would use this git metadata and if that then really achieves the intent you have.

it is important to perform correct attribution, because it is fair to make it traceable in statistics, who sponsored the work - you can argue on the importance of this, but it's a fact that the sponsor is more obvious, in this way

Sure, correct attribution is important. Just for your information: an alternative I have seen was to have the name set to "Firstname Lastname (Company) xyz@kernel.org" where kernel.org is of course not related to the Company, but just a general email account for kernel developers. Then, you also sign off with this identity, and the company affiliation is clear and the DCO check is clear and simple as well.

As elisa-tech repository are just used for work in progress---final documentation goes into the linux-kernel repository---, there is nothing to worry about here anyway.

[igor-stoppa]

@bulwahn

Sure, correct attribution is important. Just for your information: an alternative I have seen was to have the name set to "Firstname Lastname (Company) xyz@kernel.org" where kernel.org is of course not related to the Company, but just a general email account for kernel developers. Then, you also sign off with this identity, and the company affiliation is clear and the DCO check is clear and simple as well.

Yes, I actually considered that, before sticking to the signed-off-by that the automation doesn't like, and then I rejected the idea.

To me it looks really wrong to use a workaround (that's what it is), like the same person signing off twice, just to satisfy the shortcomings of an automatic check that should generate a warning instead of an error.

[igor-stoppa]

@reiterative talking insted about real issues with the submission: I was not exactly sure of the way to represent urls pointing to the repo itself. In the .md files, each file is pointing to its respective seeding pdf, but the url might not be ok. I'd prefer to fix that, if needed, once the pull with the pdf is merged.
Similarly, I noticed a few places where the rendering of markdown on github is a bit different from the preview on the editor I used. I would like to have a followup pull dealing only with cosmetics.

[reiterative]

Approving on the basis discussed in comments and in meetings.

[reiterative]

Approving for merge as a contribution, as a basis for further review and derivation.