AW: AW: [PATCH 1/3] Remove duplicate GRETH driver

[Gabriel.Moyano at dlr.de]

>>>>> Hi Jiri,
>>>>>
>>>>> My understanding was that one driver version was meant to be used 
>>>>> with
>>> drvmgr (greth.c) and the other without it (greth2.c). May I ask why 
>>> do you've chosen to remove greth.c and not greth2.c?
>>>
>>> I have fixed-up the greth.c file to avoid inline SPARC assembly code, 
>>> but the file is not used even when RTEMS is compiled with 
>>> --enable-drvmgr. The problem is that both greth2.c and greth.c are 
>>> compiled, and as they define the same symbols, greth2.c is pulled in 
>>> first by chance.
 
I think the symbols of greth.c are linked into the final binary when CONFIGURE_DRIVER_AMBAPP_GAISLER_GRETH is defined (drvmgr_confdefs.h).
I hope this helps

>>>I need to disable the building of the network files 
>>> in bsps/shared/shared-sources.am when -- enable-drvmgr is defined. 
>>> Does anyone know how to do this? My skills in m4 etc. are limited ... 
>>> :-(
>>>
>> If 99% of the code are the same, would it be an option to have just one driver implementation and in the drvmgr just use a wrapper for the driver?

>This is my idea to, but the driver manager code is sprinkled out in the file so it might take quite a few >ifdefs to fix. In any case, I still need to fix the m4 macros to detect if driver manager is defined or not ...


>>
>> Best regards,
>>
>>     Jan
>>
>>>> The problem I had was that greth.c contains SPARC assembly code and 
>>>> cannot be built on any other architecture. I will change my patch to 
>>>> disable greth.c on non-SPARC targets or try to replace the asssembly 
>>>> code with macros as in greth2.c. Thanks for the feedback!
>>>>
>>>> An other issue is that the two files are 99% identical, but only 
>>>> greth,c seems to be maintained. PHY handling and multi-cast support 
>>>> are areas where the files have diverged. But this is an other discussion ...