Open ReinhardKeil opened 11 months ago
Related to #22
Reinhard,
Can you explain the way you have define the list of "mode" you propose ? In particular I do not understand the rational of the "Device" mode and the consistency of a "bundle" mode vs some others e.g "open" mode is unclear to me. Furthermore, Device is already a Cclass to using it also as mode is confusing and in the same way "api" is also already an element.
For a better understanding of the mode idea, can you map the mode to the existing Cclass ? in your foreseen usage of mode is the mapping fixed or can it depends on the pack contents e.g for components with a Cclass 'graphics' can some be mapped on a mode 'bundle' and others on the mode 'controlled' or 'open' ? To my understanding the 'mode' is used to check if Cgroup can be added or not. Do you confirm ? Consequently, to my understanding of your proposal, Cclass list is fixed (limited to the existing list in Open-CMSIS-Pack spec) and enforced using Packchk. Any new Cclass addition will have to be approved by a CCB, Is it what you have in mind ?
We have a better description here: https://github.com/Open-CMSIS-Pack/open-cmsis-pack-taxonomy
Also there is a start of the mapping in this file https://github.com/Open-CMSIS-Pack/Open-CMSIS-Pack-Taxonomy/blob/main/Open-CMSIS-Pack-Taxonomy.yaml
Any new Cclass addition will have to be approved by a CCB, Is it what you have in mind ? Yes, I think this is what is required to ensure compatibility.
I believe we need further work on the mode "Bundle". Let's see what feedback we can get here.
Open-CMSIS-Pack should enable software re-use across software vendors and companies. To achieve this we need guidelines and this talks about the usage of
Cclass
/Cgroup
.Software components are defined with the element
<component>
. Application Programming Interfaces (API) are defined with the element<api>
. Both useCclass
andCgroup
names to organize selectable components for software re-use.Each
Cclass
and every selectedCclass
/Cgroup
should have one of the following modes that are validated bypackchk
.Cgroup
names. As a component has also aCvendor
, an name clash between different vendors can be resolved. Still it is recommended to avoid name clashes at theCgroup
level.Cgroup
names are allowed, but each component must have a dependency to a device (otherwise similar to Mode: Open).Cgroup
names are allowed, but each component must have a dependency to a board (otherwise similar to Mode: Open).Cclass
are possible, but controlled by the Open-CMSIS-Pack working group or by the Owner (=vendor). CMSIS, LVGL, or Memfault could be examples for such a Cclass.Cgroup
names can only be added using the sameCvendor
name. It is possible to have multiple bundles that use the sameCclass
name.exclusive
one or more implementations may be provided. This mode is triggered by the element<apis>
of a software pack.An unexpected element.
Cclass
orCgroup
naming clash may result to incompatible operation of the Open-CMSIS-Pack system. Sometimes even established software packs become unusable or users get confused by way components are represented. It is therefore required to organize theCclass
/Cgroup
taxonomy at the level of the Open-CMSIS-Pack project beyond the current information in the Open-CMSIS-Pack specification that is described under theThe implications (that should be verified by tools like
packchk
) of the different modes are:Cgroup
names are accepted. There might be a check for duplicates in other packs.Cgroup
names are accepted. There is a check for a device condition as the components are device specific.Cgroup
names are accepted. There is a check for a board condition as the components are boards specific.Cgroup
are checked againstOpen-CMSIS-Pack-Taxonomy.XML
. If not present, rejected.Cgroup
names are accepted. There is a check that a bundle with name is defined.Proposed steps:
Open-CMSIS-Pack-Taxonomy.XML
(or YML) file that lists validCclass
definitions, along with above mode information, owner (= vendor), contact (= email), description, and optionalCgroup
information.Open-CMSIS-Pack-Taxonomy.XML
file. Add Cgroup information where required.Open-CMSIS-Pack-Taxonomy.XML
file is used by packchk for validation but could be also used to display information about the registered Cclass/Cgroup.Open-CMSIS-Pack-Taxonomy.XML
. Implement a contribution process similar to Simple-Icons