[PATCH] build: Add RTEMS_QUALIFIED

Tue Nov 7 23:22:02 UTC 2023

I thought you would "verify" a package by looking at the symbols that
end up included in the binary.
And then have some sort of mapping between the symbols <> tests <> requirements.

Any extra symbols not in the verification "database" would end up as a
flag that a new test / requirement needs made.

On Tue, Nov 7, 2023 at 6:18 PM Gedare Bloom <gedare at rtems.org> wrote:
>
> On Mon, Nov 6, 2023 at 1:55 PM Chris Johns <chrisj at rtems.org> wrote:
> >
> > On 6/11/2023 8:27 pm, Sebastian Huber wrote:
> > > 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.
> >
> > I think we should also include in our discussion code contained within this
> > define (or defines) in shared files and how we manage changes to that code? In
> +1
>
> > an ideal world we would not have any need for conditional code however I
> > appreciate this may not be possible or initial achievable. We should however
> > look for approaches that try to avoid this and understand the constraints the
> > define brings. For example can I change code in a qualification or FACE define
> > when I do not know the standards they support?
> >
> +1
>
> For now these are the two things that stand out to me about this
> patch. Historically, we have tried to get away from CPP defines to
> tailor builds at a global level. I'm not sure the extent of what must
> be split within a file, versus what can be split/qualified at a file
> level. Assuming one qualifies API subsets, then I would imagine it
> would be the entire set of files brought in by those subsets. I'm not
> interested in maintenance burden of two versions of basically the same
> code. This will eventually lead to inconsistencies. I understand the
> intent may be to have a code base closer to what can be ultimately
> qualified, but I see this as problematic from a long-term maintenance
> perspective.
>
> What I see here is that certain APIs are being circumvented presumably
> because they are not part of someone's qualified package. As far as I
> know, the goal of pre-qual was never to create qualified packages, but
> to make it easier for downstream users to make qualified packages of
> their choosing. Pushing constraints back into rtems.git because of an
> inability to qualify some parts of the code is opposite of the goal.
> It is like a somewhat kinder form of stripping down RTEMS to what is
> qualified and shipping that, which is what I understood to be the
> previous methodology that should be avoided.
>
> I would also not like to see variations of the same files for
> different "profiles" or qualified targets.
>
> Gedare
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

-- 
Sincerely,

Sam Price