Self-contained POSIX synchronization objects for RTEMS 4.12?

[Gedare Bloom]

On Wed, Sep 20, 2017 at 1:48 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> 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.,

RTEMS_DEBUG_KERNEL
RTEMS_DEBUG_VALIDATE_ARGS
RTEMS_DEBUG_HEAP
RTEMS_DEBUG_DEADLOCK_DETECTION
RTEMS_DEBUG_FILESYSTEM
RTEMS_DEBUG_SMP_LOCKS

and then some aggregates like
RTEMS_DEBUG_SMP
RTEMS_DEBUG_SYNCHRONIZATION
RTEMS_DEBUG_MEMORY

and a catch all
RTEMS_DEBUG_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.

-Gedare