On Tue, Mar 8, 2022 at 12:45 AM Sebastian Huber < 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>> 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> > > > > > > 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. > > This change needs to be looked at (the comment in the file header makes > no sense after this change): > > commit 7f3c6cee09ee44b627b11de34248aba485c789b3 > Author: Joel Sherrill <joel.sherr...@oarcorp.com> > Date: Tue Dec 4 22:20:55 2007 +0000 > > 2007-12-04 Joel Sherrill <joel.sherr...@oarcorp.com> > > * amba/amba.c, clock/ckinit.c, console/console.c, > include/bsp.h, > startup/bspstart.c, timer/timer.c: Move > interrupt_stack_size field > from CPU Table to Configuration Table. Eliminate CPU Table > from all > ports. Delete references to CPU Table in all forms. > > diff --git a/c/src/lib/libbsp/sparc/leon3/timer/timer.c > b/c/src/lib/libbsp/sparc/leon3/timer/timer.c > index 9d6f89a593..2c1127a30a 100644 > --- a/c/src/lib/libbsp/sparc/leon3/timer/timer.c > +++ b/c/src/lib/libbsp/sparc/leon3/timer/timer.c > @@ -22,12 +22,13 @@ > > #include <bsp.h> > > -extern rtems_configuration_table Configuration; > - > -#define LEON3_TIMER_INDEX \ > - (Configuration.User_multiprocessing_table ? \ > - (Configuration.User_multiprocessing_table)->maximum_nodes + \ > - (Configuration.User_multiprocessing_table)->node - 1 : 1) > +#if defined(RTEMS_MULTIPROCESSING) > + #define LEON3_TIMER_INDEX \ > + (rtems_configuration_get_user_multiprocessing_table() ? : \ > + (rtems_configuration_get_user_multiprocessing_table()->node) - > 1 : 1) > +#else > + #define LEON3_TIMER_INDEX 0 > +#endif > > rtems_boolean Timer_driver_Find_average_overhead; > > > > > -- > 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
