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 <ged...@rtems.org> wrote: > > On Mon, Nov 6, 2023 at 1:55 PM Chris Johns <chr...@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.hu...@embedded-brains.de > > >>>> <mailto:sebastian.hu...@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel -- Sincerely, Sam Price _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
