On Wed, Sep 20, 2017 at 1:48 AM, Sebastian Huber <sebastian.hu...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
