On Tue, Mar 8, 2022 at 8:46 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote:
> 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. > That's how it is now. #if defined(RTEMS_MULTIPROCESSING) #define rtems_configuration_get_user_multiprocessing_table() \ ( &_MPCI_Configuration ) #else #define rtems_configuration_get_user_multiprocessing_table() NULL #endif I think all the use cases Ryan and I saw were protected by ifdef RTEMS_MULTIPROCESSING. Perhaps this just should not be defined if it isn't configured. --joel > > -- > 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
