Multi-Context Terminology & Concepts

jkrech commented 2 years ago

STMicroelectronics contributed this document aiming to define a common set of terms and concepts for describing and managing multiple dependent projects as outlined in issue https://github.com/Open-CMSIS-Pack/Open-CMSIS-Pack/issues/12

https://github.com/Open-CMSIS-Pack/Open-CMSIS-Pack/files/7279772/Multi-Context_Concepts_OpenCMSIS.pdf

Proposal: Terminology and definitions shall be reviewed and discussed and added to the glossary once agreed

fred-r commented 2 years ago

Hi all,

no comments so far, so can i go ahead with PRs to include it in the glossary ?

Thanks & Regards, Fred

fred-r commented 2 years ago

Important concepts to clarify:

Is the workspace the user's property where he can put whatever he wants ?
Based on that can the workspace bring flexibility by including projects and layers ?
What flexibility do we really need at solution/application project level ? What price can we afford here to avoid creating a very complex and counter-intuitive system ?

fred-r commented 2 years ago

Of course this also depends on how you see the tool : single instance multiple projects or multiple instances with 1 project each ? I am more in favor of the first option to allow moving and copying artefacts between projects : a real "place to work" (workspace)

brondani commented 2 years ago

@fred-r I read again your definition of "Application Project". Unfortunately "Application" is often defined in computing encyclopedia as being only the top part of a software stack or solution stack. For this reason I believe the term "solution" is more adequate in the CMSIS Project Manager scenario similarly to the VS terminology.

_Solution stack In computing, a solution stack or software stack is a set of software subsystems or components needed to create a complete platform such that no additional software is needed to support applications. Applications are said to "run on" or "run on top of" the resulting platform._

fred-r commented 2 years ago

@fred-r I read again your definition of "Application Project". Unfortunately "Application" is often defined in computing encyclopedia as being only the top part of a software stack or solution stack. For this reason I believe the term "solution" is more adequate in the CMSIS Project Manager scenario similarly to the VS terminology.

_Solution stack In computing, a solution stack or software stack is a set of software subsystems or components needed to create a complete platform such that no additional software is needed to support applications. Applications are said to "run on" or "run on top of" the resulting platform._

Well, I agree that in TCP/IP model/stack for instance we have the application layer. But, that's why I am not suggesting "Application" alone but "Application Project".

We may call it "application product" if you prefer: https://en.wikipedia.org/wiki/Application_software

What is important to me is this notion of an entity providing a service to the end-user so implementing the use-cases of the final product. To me we are clearly targeting an "Application Product" embedding the applicative part, the system software part and the required hardware to run it.

With solution, I am afraid we are focusing too much on the software only. And here also we are touching a point of disagreement : to me an "Application Product" is comprising the hardware because it is fully dependent on the HW capabilities.

Your application software will very quickly diverge from one HW to another : not the same drivers, not the same buttons/leds/parts, not the same memory map.

So to me an "Application Project" or "Application product" is really targeting one hardware but it can reuse:

a same software project (or several)
or a same layer within a software project (or several) from one "Application Project" to another.

This is where we factorize.

If we try factorizing at "Application project" level then we end up with many "profiles" with completely different components and settings. We lose lots of clarity and I am not sure we gain flexibility : the layers and SW projects are there anyhow for this flexibility.

If on top of this we have a Workspace concept which is really the place where the user works then the end-user can have several "Application Projects" open in parallel and do copy/paste or whatever he wants to have some reuse and factorization in the end.

Mixing everything under one generic term like "solution" would bring mainly confusion in my opinion and I am not sure the flexibility would be better. Would you manage to keep one software project with low level layers ? Maybe if you implement lots of rules to select a component instead of another or apply a memory mapping instead of another based on...the hardware capabilities.

So, to me, it is easier to factorize the software layers which are generic (same code) but keep different "Application Projects" gathering the HW-dependent choices.

fred-r commented 2 years ago

@0Grit and @ilg-ul: Did you have a look at these concepts and terminology ? Would you agree with it ?

ilg-ul commented 2 years ago

I went through the document until I noticed the red markings with 'ST Confidential'. Since I don't have an NDA with ST, I stopped.

fred-r commented 2 years ago

I went through the document until I noticed the red markings with 'ST Confidential'. Since I don't have an NDA with ST, I stopped.

My bad : I forgot to remove this classification...the document is not confidential any more.

fred-r commented 2 years ago

Pull-request proposed for the terms we agreed on: https://github.com/Open-CMSIS-Pack/Open-CMSIS-Pack/pull/63

ReinhardKeil commented 2 years ago

I would suggest that we review this concept. From glancing over, looks similar to CMSIS-Zone, might be good to map the concept to CMSIS-Zone (perhaps with a table - see attempt below). I think it highlights some missing pieces in CMSIS-Zone, for example the Initialization Context, Execution Modules, Execution Groups (concurrent execution).

ST multi-context	CMSIS-Zone	Description / Questions
Execution Context	Project Zone	A collection of resources that are allocated to one (or if no concurrent execution happens) project.

Since this deals also with TrustZone, I think we should map it to TF-M and see if there are gaps.

fred-r commented 2 years ago

Regarding the execution context, I agree that it is quite coupled with the resources, you are right. Besides, in the tool UI it might be overkill to distinguish this concept from the concept of execution domain.

But the intention was:

to have the execution context linking a software project with an HW execution unit
to have the execution context as the top level entity to gather several execution modules if needed
to have the execution context as the top level entity to address an execution domain and shared domain

Having the concepts of execution context and execution domain brings the possibility to define the shared execution domain (used by several execution contexts).

Disclaimer: we think it is good to split in different concepts the elements we need to handle. This allows a clear split of roles and better thinking. Nevertheless, all these concepts will not necessarily be shown to the end-user, the tool may very well abstract them for the sake of simplicity (example: the difference between execution context and execution domain is not needed for the end-user).

ReinhardKeil commented 2 years ago

Fred are you ok with the terminology that we are today using or should we change anything? Should we add a Glossary to the documentation?

fred-r commented 2 years ago

Hi Reinhard,

we are finalizing an update of the terminology to address both Cortex-A and Cortex-M. Based on this proposal (to be issued within 2 weeks), I think it would be good to update the glossary.

Open-CMSIS-Pack / Open-CMSIS-Pack-Spec

Multi-Context Terminology & Concepts #33