Self-contained POSIX synchronization objects for RTEMS 4.12?
gedare at rtems.org
Wed Oct 4 14:32:57 UTC 2017
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
>> 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
>> testing is only helpful. Changing the environment, ie the kernel without
>> on, invalidates the previous testing. Any change without a careful and
>> 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?".
>> 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
>> to the tests and the collected results.
>> I wonder if there is a case of looking to hard, for example I could see a
>> 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
>> you need to cater for.
>> I view RTEMS_DEBUG as a develop aid for those working within RTEMS. It
>> 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
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