Self-contained POSIX synchronization objects for RTEMS 4.12?

[Chris Johns]

On 20/09/2017 03:43, Sebastian Huber wrote:
> ----- Am 19. Sep 2017 um 16:40 schrieb Gedare Bloom gedare at rtems.org:
>> On Tue, Sep 19, 2017 at 10:09 AM, Joel Sherrill <joel at rtems.org> wrote:
>>> On Tue, Sep 19, 2017 at 8:16 AM, Sebastian Huber
>>> <sebastian.huber at embedded-brains.de> wrote:
>>> Newlib/Cygwin folks have been pretty insistent that they do not want to
>>> check for NULL on the shared methods.
>>>
>>> Personally I hate to delete NULL argument pointer checks. Would a
>>> long-term compromise be to move them to argument checking macros
>>> that are enabled with --enable-rtems-debug?
>>>
>>>>
>>>>
>>>> Do we want to check for other obviously invalid pointer values, e.g.
>>>> SEM_FAILED?
>>>
>>>
>>> IMO Yes
> 
> With the move to self-contain objects the storage space management moves from the system to the user.

This is sort of correct, the user always has to manage the storage allocation,
system, user or other, all we are doing is changing the mechanism being used.
The user of an object creates the allocation where we previously needed to
specify the quality and allocate the memory in the workspace and any failure was
only detected at runtime.

I think 'self-contain' objects is a nice model to adopt because it statically
manages a number of system space issues, if there are too many objects the
linker will tell us. I feel long term the kernel should move to all resources
being self contained so a user knows the object counts in the configuration are
for them. It will also make the test configuration simpler because object
resources in drivers, BSP code or services in RTEMS vary from BSP to BSP.

> This makes it hard for the system to validate things.  I am not sure if we should check for error conditions that shouldn't be present in production code.

The fact you say 'should' here means there is some doubt. There can be no doubt
or you need the checks.

>  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?

Chris