[PATCH 10] IO_MANAGER: early dynamic driver registration

[Daniel Hellstrom]

On 02/03/2012 06:26 PM, Joel Sherrill wrote:
> Sorry to cut this down but this is the crux of the problem.
>
> On 02/03/2012 10:33 AM, Daniel Hellstrom wrote:
>>> >>  boot_card() is the master initialization sequencer.  Sebastian is
>>> >>  right that you can use the bsp_pretasking_hook() or you can
>>> >>  use the bsp_predriver_hook().
>> >  Without the patch however, rtems_io_initialize() is called twice for every dynamically register driver from bsp_predriver_hook().
>> >
> Given that as the issue, I wondered if there are enough
> system states to solve the issues. The answer is no.
> There is no system state change between
> SYSTEM_STATE_BEFORE_MULTITASKING and
> SYSTEM_STATE_BEGIN_MULTITASKING.
>
> There were always steps in the initialization sequence
> of "RTEMS readiness" which could have been noted
> but there was no requirement to do so.
>
> Would it make sense (and solve this problem) to add at
> least one more state? In particular, at least a state at
> the end of initializing all drivers to indicate that drivers
> have been initialized?
>
> I can also see a state for "initializing drivers" because
> a solution to this problem might require that to support
> registering during initialization.
>
> NOTE: Any solution like this needs to evaluate the uses
> of the system states as defined. It would be easy to
> break something. :)
>
The problem for me is that I don't really understand why the IO Manager internal states has anything to do with the system state. As long as the IO manager fulfills the API it provides there should 
not be a problem. If all managers would need an additional system state to solve their internal problems there would be a lot of states.

Daniel