Changes between Version 53 and Version 54 of Developer/Projects/SequencedInitialization

Jun 18, 2010, 6:42:41 AM (9 years ago)

/* Open Projects */


  • Developer/Projects/SequencedInitialization

    v53 v54  
    272272 SYSINIT_REFERENCE(_Message_queue_Manager_initialization);
     273=  Summary of RTEMS Sequenced Initialization Error_Handling IRC meeting  = 
     274(attender DrJoel, sebhub, gedare, zwj. all is IRC name)
     276In june 16 there is a IRC meeting talking about RTEMS Sequenced Initialization Error_Handling. There is a
     277error handler in the RTEMS code naming rtems_fatal_error_occured which maybe depends on some
     278initialization steps. But DrJoel pointed out that the Sequenced Initialization code is after the initialization of rtems_fatal_error_occured. So it will be ok to call the error handler. The RTEMS Sequenced Initialization Error_Handling is designed to invoke the fatal error handler themselves when something goes wrong and we want it to grow to later initialization points and user code such as initializing bdbuf via this mechanism or drivers. And initialization fatal errors are reserved for things that are truly horrible and reflect an inconsistent system configuration that you shouldn't be allowed to run the first task with Lab failures. RTEMS is not a desktop OS, every fatal error is dangerous. Then at the moment it is reasonable that we specifiy all errors during the sysinit invokation are fatal. So The entire set of these errors is in an enum, there is no need to check the return status for RTEMS purposes. Gedare suggested that we can configure whether an initialiation error is fatal or not. But this will make it more complicated and errors during initialization are software or configuration bugs, such applications are not worth to live long. So it is not worth doing that.