RFC: doc: glossary: Consolidate "software component" as a term

[carlescufi]

In order to define different parts of the Zephyr codebase, we first need a clear term that defines what a "part of the software" is, so generalize the existing term "software component" to be used from now on as the standardized term.

Given that the kernel is currently defined, as per: https://docs.zephyrproject.org/latest/kernel/services/index.html as:
"The Zephyr kernel lies at the heart of every Zephyr application. It provides a low footprint, high performance, multi-threaded execution environment with a rich set of available features. The rest of the Zephyr ecosystem, including device drivers, networking stack, and application-specific code, uses the kernel’s features to create a complete application."

label it as a software component as well.

[mathieuchopstm]

Seems fine to me otherwise

[mathieuchopstm]

hardware-agnostic core

would mean that arch is not part of the kernel, which sounds wrong?

[carlescufi]

Thanks! That is exactly the kind of discussion I wanted to have here. I am very much OK with arch being part of the kernel component, so I am completely fine with removing the hardware-agnostic part and even specifically mentioning the arch part as part of the kernel.

[mathieuchopstm]

To be clear, I have no issues with hardware-agnostic core by itself; however, if we keep it (and if arch is indeed considered part of the kernel!), then arch should be explicitly mentioned as also being part of the "kernel" software component in addition to the HW-agnostic code, e.g. roughly:

Suggested change

	The :term:`software component` in Zephyr that provides the
	hardware-agnostic core of the RTOS, including booting, threading,
	scheduling, synchronization, user mode, memory management and more.
	The :term:`software component` in Zephyr that provides the
	hardware-agnostic core of the RTOS, including booting, threading,
	scheduling, synchronization, user mode, memory management and more,
	as well as architecture-specific implementation of certain routines
	used by the hardware-agnostic code.

Another wording (without the hardware-agnostic part) is possible too, but IMO your proposal is fine except for this tiny detail.

[carlescufi]

Thanks @mathieuchopstm! I will wait for more feedback from others before I make any changes. Your proposed change is fine with me.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[nashif]

thank you for taking care of this, I think a review of terminology used and making things less confusing in our docs and codebase is long overdue, however, we should try to have a deep review and fix this once and for all and take any major actions needed (renaming stuff) in one single step. few comments.

• I guess the main driver for this is the fact that we have drivers being classified as subsystem? Well, I guess it was necessary at some time to call them something and we might have picked the wrong name and if it is a problem, we probably need to address this.
• if we are going this path, I would remove this section completely and just rely on this being defined in the gloassry, no need to keep it duplicatated here.
• Also, I would look across the documentation and the code base and address existing usage of subsystem
  • example, take https://docs.zephyrproject.org/latest/kernel/usermode/kernelobjects.html where usage of 'driver subsystems' is common. What changes do we need to make there and in the code to make this compatible with the new definition, or we do not need to touch it at all?
  • also look at other items in the gloassary and define how those relate to SC
  • visualizing all of this would be very helpful, maybe using some of our existing (probably outdated) architecture diagrams
• Based on this definition, everything is a a component, a device driver class is a component, a driver is a component, a sample using those drivers is a component, so I am not sure how useful this is, looking at our docs, there are 4 mentions, 2 of which go bak to ETSI, see below:
• Many related standards/project define software component already, need to make sure we do not conflict or overload the definition, or it will be confusing to users:
• Autosar: AUTOSAR software components are reusable building blocks of AUTOSAR software. An AUTOSAR software component encapsulates one or more algorithms and communicates with its environment through well-defined ports. For example, a throttle application might include AUTOSAR software components that represent sensors for throttle and acceleration pedal sensors, a throttle position monitor, a controller, and an actuator.
• IETSI:
  a general term used to refer to a software system or an element, such as module, unit, data, or document. IEEE Std 1061-1998 (R2004) IEEE Standard for Software Quality Metrics Methodology.2.2. 2. a functionally or logically distinct part of a software configuration item, distinguished for the purpose of convenience in designing and specifying a complex SCI as an assembly of subordinate elements"