On 3/13/2014 9:59 AM, Sebastian Huber wrote: > On 2014-03-13 15:53, Joel Sherrill wrote: >> This is the best way to remove the warnings. >> >> Longer term, we should address rtems_bsp_delay() as a >> generic BSP interface or provide it in a more uniform way. > We already have this: > > http://www.rtems.org/onlinedocs/doxygen/cpukit/html/group__ClassicCounter.html > > The proper way is to get rid of this rtems_bsp_delay() entirely. > Where does this work now?
+ All SPARC BSPs? + All PowerPC BSPs? + pc386? + which ARMs? + other? My grep shows that if a few NIC drivers are fixed, there do not appear to be many uses in non-BSP specific code. There is powerpc-utility.h in libcpu which needs to be looked at. And there is a related rtems_bsp_delay_in_bus_cycles which is used in some PowerPC BSPs. My point is that there are currently a few uses outside BSPs which need to be addressed before this can be eliminated. Since some of the uses are NICs which have conditionals on PPC and x86, having counter work there would be sufficient I think to change them. Beyond that, it would be a per-BSP issue that is quick to eliminate I think. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
