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
