On 08/03/2022 15:23, Joel Sherrill wrote:
On Tue, Mar 8, 2022 at 12:45 AM Sebastian Huber <sebastian.hu...@embedded-brains.de <mailto:sebastian.hu...@embedded-brains.de>> wrote:On 07/03/2022 19:19, Joel Sherrill wrote: > > > On Mon, Mar 7, 2022 at 11:54 AM Sebastian Huber > <sebastian.hu...@embedded-brains.de <mailto:sebastian.hu...@embedded-brains.de> > <mailto:sebastian.hu...@embedded-brains.de <mailto:sebastian.hu...@embedded-brains.de>>> wrote: > > On 07/03/2022 17:48, Joel Sherrill wrote: > > This appears to be because > > rtems_configuration_get_user_multiprocessing_table() always returns a > > non-NULL value when RTEMS_MULTIPROCESSING is defined. This must > be a change > > versus previous behavior. > > > > Ryan and I noticed that the specific cases cited here appeared to be > > wrapped in ifdef RTEMS_MULTIPROCESSING so didn't need to worry > about it. > > But something has changed that impacts public facing behavior. > > I think this is the related ticket: > > https://devel.rtems.org/ticket/3735 <https://devel.rtems.org/ticket/3735> > <https://devel.rtems.org/ticket/3735 <https://devel.rtems.org/ticket/3735>> > > > OK. But apparently this was used to tell the difference between a > single node system in MP configuration and a node within an > MP configuration. My grep shows some uses are really dereferencing > the table but others like the one in amba.h:153 to define the clock > index looks wrong. THere is similar code in leon.h: > > #if defined(RTEMS_MULTIPROCESSING) > #define LEON3_CLOCK_INDEX \ > (rtems_configuration_get_user_multiprocessing_table() ? > LEON3_Cpu_Index : 0) > #else > #define LEON3_CLOCK_INDEX 0 > #endif > > That's the type of pattern that needs addressing. That test is > asking in multiprocessing is configured in the application not > in the build. The rtems_configuration_get_user_multiprocessing_table() ? X : Y expressions can be simplified to X. That does not preserve the semantics of the original. In the original implementation, it could return NULL for an application configured to be a single processor with no distributed multiprocessing in use. The change gets rid of the warning but doesn't 'retain the intent.
If you think the original behaviour of rtems_configuration_get_user_multiprocessing_table() is important, then it should be documented and tested.
-- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@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/ _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
