[PATCH] build: Add RTEMS_QUALIFIED

Chris Johns chrisj at rtems.org
Mon Nov 6 00:14:57 UTC 2023


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?

Chris


More information about the devel mailing list