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

Jiri Gaisler jiri at
Wed Oct 28 14:34:24 UTC 2020

On 10/28/20 8:57 AM, Gabriel.Moyano at wrote:
>>>>>> 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
Thanks, this helped a lot. But I still think that compilation of greth.c
and greth2.c must be mutually exclusive since they define the same
symbols. I will follow Sebastian's advise and use the new waf system
(once I have figured it out ...).
>>>> I need to disable the building of the network files 
>>>> in bsps/shared/ 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 ...

More information about the devel mailing list