[PATCH 10] IO_MANAGER: early dynamic driver registration

[Daniel Hellstrom]

On 02/03/2012 05:21 PM, Daniel Hellstrom wrote:
> On 02/03/2012 03:02 PM, Joel Sherrill wrote:
>> On 02/03/2012 07:48 AM, Sebastian Huber wrote:
>>> On 02/03/2012 11:39 AM, Daniel Hellstrom wrote:
>>>> On 02/03/2012 08:45 AM, Sebastian Huber wrote:
>>>>> On 02/02/2012 03:46 PM, Daniel Hellstrom wrote:
>>>>>> Adds the possibility to register drivers before the IO Manager has
>>>>>> completed the initialization. Sometimes the BSP may want to register
>>>>>> a driver dynamically early in the boot process.
>>>>>>
>>>>>> Signed-off-by: Daniel Hellstrom<daniel at gaisler.com>
>>>>> Isn't it possible to use the system state for this? This would make this
>>>>> additional global variable superfluous.
>>>> That would break code that register drivers after the IO_Manager has been
>>>> initialized and before the system state is updated. That would break my
>>>> particular use case just because of that. Besizes , the IO manager will depend
>>>> on the system state, but is okay I guess? I can also change from a int to a
>>>> char to reduce data increase with only one byte?
>>>>
>>>> What do you think?
>>> I guess you use the boot_card() function to start your system?  At which point
>>> do you registers these BSP specific drivers?  Can't you use the
>>> bsp_pretasking_hook() or CONFIGURE_BSP_PREREQUISITE_DRIVERS?
>>>
> Yes, bootcard.c is used for initialization. With the current implementation it does not work to register an IO driver before the IO subsystem is initialized at all.
>
> You suggest to use the system state, then if finding a hardware device depends on driver that isn't initialized until _IO_Initialize_all_drivers() then that driver will register after 
> _IO_Initialize_all_drivers() but before system state update. For example if registered in bsp_postdriver_hook().
>
>> It sounds like Daniel wants to register drivers before RTEMS has had
>> a chance to initialize its data structures. That is going to be
>> problematic.
> That is most of my problem, that does currently not work. In some rare cases drivers are also registered after IO Manager has been initialized, but before rtems_initialize_start_multitasking().
Sorry, drivers are never registered before rtems_initialize_data_structures() or _IO_Manager_initialization().

>
>>
>> What type of drivers are you registering?
> Some of the problem is that we have drivers that the user may choose to register manually from the Init() task, or let the BSP do the registration on boot. Since the driver's "register function" is 
> implemented the same way in both cases the driver will call rtems_io_register_driver(), either from Init() or during boot.
>
> The next problem is that when we use our "unofficial" driver manager the device finding is split into several steps, this way drivers can depend on each other. However that is not a problem in RTEMS 
> until the driver manager is used. The driver manager finds the device for a driver to lower the footprint of drivers (drivers of the same bus type use the same way to find their devices in Plug&play 
> systems), it is faster to register a driver when the first device instance is found instead, besides the driver structure can be smaller. This apply for binaries that target multiple systems where 
> the devices are plug&played (LEON3/4, PCI, MII-PHY bus etc.), I believe RTEMS does not really target binaries/systems like at the moment.
>
> One type of binary that we often use is a demo application which include all our drivers, the RTEMS shell is started and one can see which devices have been found, at what addresses they are, the 
> IRQ numbers, and at which point a driver failed to initialize (if so), one may also can see the configuration of the drivers (which arguments to register driver was used, sort of), regardless of PCI 
> Host controller one may access PCI, and so on. I personally think it much easier for customers to start RTEMS development like that, later a more optimal configuration is created.
>
>>
>> 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().
>
>>
>> CONFIGURE_BSP_PREREQUISITE_DRIVERS was added so the
>> BSP can ensure a required driver runs first.  The
>> CONFIGURE_APPLICATION_PREREQUISITE_DRIVERS was
>> actually added by a user who had an ERC32 based VMEBus
>> board. They used that configuration point to ensure the
>> VMEBus was initialized before any drivers accessed it.
>>
>> A general issue is that dynamically registering drivers requires
>> that the application configure driver slots for them. By default,
>> there are no slots for dynamically registered drivers. So this is
>> imposing a configuration requirement from the BSP.
> True, we use CONFIGURE_MAXIMUM_DRIVERS to make space in the driver table for dynamically registered drivers.
>
>>
>> I think backing off to understand your requirement would be
>> a good thing to do.
>
> Maybe there is a better way going about, but this way works fine for us, at the moment there are more than 40 drivers using this technique.
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>
>