[PATCH] build: Add RTEMS_QUALIFIED

[Sebastian Huber]

On 06.11.23 01:14, Chris Johns wrote:
> On 4/11/2023 1:31 am, Sebastian Huber wrote:
>> On 03.11.23 15:08, Joel Sherrill wrote:
>>> On Fri, Nov 3, 2023 at 3:58 AM Sebastian Huber
>>> <sebastian.huber at embedded-brains.de
>>> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>>>
>>>      The goal of the RTEMS pre-qualification activity #3701 is a specified
>>>      and validated subset of RTEMS.  For users of the pre-qualified subset of
>>>      RTEMS it is important to not accidentally use not pre-qualified
>>>      features.  One way to achieve this, is to build only the sources of the
>>>      pre-qualified feature set. This customized build is enabled by the new
>>>      build configuration option RTEMS_QUALIFIED.  If it is enabled, then only
>>>      the pre-qualified subset of RTEMS is built and installed.
>>>
>>>      Building with RTEMS_QUALIFIED enable is currently only supported for the
>>>      sparc/leon3 BSP family.  To support an RTEMS_QUALIFIED enabled build,
>>>      changes in the CPU port and the BSP are required to only use features of
>>>      the pre-qualified feature set.
>>>
>>>
>>> Where is this documented?
>> You mean a documentation of what needs to be done to create pre-qualified BSP? I
>> don't have it available yet. A good place to add this would be the how-to
>> section in the RTEMS Software Engineering manual.
>>
>>> This is a very large patch. Are you assuming that if "not qualified" is
>>> specified,
>>> then it is in the qualified set?
>> No, the logic is reversed. Everything is built by default. Some parts are only
>> enabled if RTEMS_QUALIFIED is not enabled, for example
>> (spec/build/cpukit/objextra.yml):
>>
>> enabled-by:
>>    not: RTEMS_QUALIFIED
> It seems counter intuitive to me. I have no idea about qual work but my limited
> understanding is everything is controlled yet this is the inverse of that and
> anything anyone adds will by default be qualified?

The goal of this patch set is to place each source and header file of 
RTEMS into two buckets, the pre-qualified bucket and the extra bucket. 
For two buckets you need just one option with two values. In the current 
patch it is RTEMS_QUALIFIED enabled or disabled.

Since Joel already brought the FACE profile into play, an alternative 
could be this approach. Lets assume that we pre-qualified the FACE 
profile interfaces of RTEMS. Use RTEMS_EVERYTHING for the I want 
everything profile. Use RTEMS_QUALIFIED for the pre-qualified profile. 
Use RTEMS_FACE_PROFILE for interfaces of the FACE profile.

The objects which are not pre-qualified would use this:

enabled-by: RTEMS_EVERYTHING

The objects which are pre-qualified would use this:

enabled-by:
- RTEMS_EVERYTHING
- RTEMS_QUALIFIED

The objects which are pre-qualified or in the FACE profile would use this:

enabled-by:
- RTEMS_EVERYTHING
- RTEMS_QUALIFIED
- RTEMS_FACE_PROFILE

Of RTEMS_EVERYTHING, RTEMS_QUALIFIED, and RTEMS_FACE_PROFILE exactly one 
option shall be enabled.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/