On 08/03/2022 15:40, Joel Sherrill wrote:
On Tue, Mar 8, 2022 at 8:31 AM Sebastian Huber <sebastian.hu...@embedded-brains.de <mailto:sebastian.hu...@embedded-brains.de>> wrote: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> > <mailto: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>> > > <mailto: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>> > > <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. The original behavior can't be re-implemented. When you made changes so there was always an MPCI Table, it fundamentally broke the assumption that one might not be present when MP is enabled.
We could change rtems_configuration_get_user_multiprocessing_table() to return NULL if CONFIGURE_MP_APPLICATION is not defined.
-- 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
