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.
From my experience SMP applications are quite sensitive to the
performance of mutexes. For example, the glibc POSIX mutex is heavily
performance optimized, however, we still have a specialized mutex for
libgomp (the GCC OpenMP run-time support):
https://gcc.gnu.org/viewcvs/gcc/trunk/libgomp/config/linux/mutex.h?view=markup
This implementation would work also on RTEMS by the way. It offers only
random fairness, so this is not a real-time synchronization primitive.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
