On 10/28/20 8:57 AM, gabriel.moy...@dlr.de 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/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 >>>>> ...
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
