Gedare Bloom started a new discussion on cpukit/include/rtems/rtems/attr.h: 
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/882#note_148517

 > +#define RTEMS_FLEXIBLE_MULTIPROCESSOR_LOCKING_LONG 0x00000400
 > +
 > +/* Generated from spec:/rtems/attr/if/flexible-multiprocessor-locking-short 
 > */
 > +
 > +/**
 > + * @ingroup RTEMSAPIClassicAttr
 > + *
 > + * @brief This attribute constant indicates that the Classic API semaphore
 > + *   created by rtems_semaphore_create() shall use the Flexible 
 > Multiprocessor
 > + *   Locking Protocol - Short variant (FMLP-S).
 > + *
 > + * @par Notes
 > + * The FMLP-S uses non-preemptive execution for short critical sections. The
 > + * semaphore shall be a binary semaphore (#RTEMS_BINARY_SEMAPHORE).
 > + */
 > +#define RTEMS_FLEXIBLE_MULTIPROCESSOR_LOCKING_SHORT 0x00000200

I'm contemplating the API ramifications of this change. While we have supported 
MrsP for quite some time, there are certainly several kinds of multiprocessor 
protocols. I wonder if we need to have a roadmap and plan to make sure we are 
being thoughtful about how we accept these as they commit us to API. In this 
case, the attribute field becomes something we have to support into the future.

-- 
View it on GitLab: 
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/882#note_148517
You're receiving this email because of your account on gitlab.rtems.org.


_______________________________________________
bugs mailing list
[email protected]
http://lists.rtems.org/mailman/listinfo/bugs

Reply via email to