>>>>> 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 >>>> ... _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel