Self-contained POSIX synchronization objects for RTEMS 4.12?

Gedare Bloom gedare at
Wed Oct 4 14:32:57 UTC 2017

On Wed, Sep 20, 2017 at 1:48 AM, Sebastian Huber
<sebastian.huber at> wrote:
> On 20/09/17 02:47, Chris Johns wrote:
>> On 20/09/2017 03:43, Sebastian Huber wrote:
>> [...]
>>>   So, making these checks RTEMS_DEBUG dependent is something worth
>>> considering.  Maybe we need a RTEMS_ROBUST option focusing on user
>>> introduced errors.  RTEMS_DEBUG enables a lot of internal consistency
>>> checks.
>> I see a contradiction here. If a debug configured environment and
>> specifically a
>> kernel you test to validate all is ok is not a production environment then
>> your
>> testing is only helpful. Changing the environment, ie the kernel without
>> debug
>> on, invalidates the previous testing. Any change without a careful and
>> precise
>> audit must be treated as a change. This leaves our users with an awkward
>> question "Should debugging or robust settings be left on for production?".
>> If
>> all testing shows the system is working and performing to specification
>> why turn
>> the settings off? If there is any doubt with that last question it must
>> relate
>> to the tests and the collected results.
>> I wonder if there is a case of looking to hard, for example I could see a
>> case
>> where you extrapolate this argument to removing malloc NULL checks in
>> production, after all the memory is fixed, the initialisation is always
>> the same
>> and malloc will never fail !! It is what you do not see not what you see
>> that
>> you need to cater for.
>> I view RTEMS_DEBUG as a develop aid for those working within RTEMS. It
>> should
>> only relate to internal consistency checks.
>> I view RTEMS_ROBUST as dangerous, is RTEMS not robust if I do not use it?
> There are some checks that help to debug broken applications. For example
> the heap protection, the deadlock detection, the file descriptor reference
> counting and simple parameter validation. A correct application doesn't need
> these checks and simply encounters a run-time penalty and some space
> overhead, but it should be tolerable. However, some internal consistency
> checks, e.g. for the SMP locks, are quite heavy weight and really hurt the
> performance.

I'm opposed to the name RTEMS_ROBUST, but not necessarily the idea of
tiering the different kinds of debug behavior. Maybe a better approach
is to introduce a set of DEBUG macros, e.g.,


and then some aggregates like

and a catch all

and for compatibility
RTEMS_DEBUG should be defined.

Such a scheme could allow for application developers to choose how
much runtime checking they require in their development/production
environments. It does mean a little more work on our end to ensure
consistent and correct use of the macros within rtems, and some
engineering to set it up.


More information about the devel mailing list