On Thu, May 18, 2017 at 2:35 PM, Pham, Phong <ph...@ddc-web.com> wrote: > > Hi Sebastian, > > I am only interested in moving rtems_fatal() implementation to a fatal.c > (thus removing the inline) and leave the indirection issue alone. Are you > comfortable with this (b4 I do the work and checkin)? In this manner, the > API remain the same. > I think this should be OK. I can't think of any good reason rtems_fatal can't be made non-inline.
> With regard to the message "Notice: This e-mail and any files transmitted > with it may contain Data Device Corporation's privileged ..." > > I don't have control of disabling the message (or maybe I don't know how). > Looks like it is automatically appended to the email. If you like, I can > switch to my personal email account whenever dealing with RTEMS (as long as > you guys are comfortable with yahoo.com email). > Yes it is preferred versus the corporate boilerplate. > Phong. > > -----Original Message----- > From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de] > Sent: Wednesday, May 17, 2017 10:16 PM > To: Pham, Phong; rtems-de...@rtems.org > Cc: Hillman, Robert > Subject: Re: rtems_fatal() as inline in a header file > > > > On 18/05/17 01:08, Pham, Phong wrote: >> >> Hi Developers, >> >> Currently: >> ...\rtems\cpukit\sapi\include\rtems\fatal.h >> <file:///%5C%5Ccentos%5Crtems-dev%5Crtems_0508%5Crtems%5Ccpukit%5Csapi >> %5Cinclude%5Crtems%5Cfatal.h> >> >> is implemented as >> >> RTEMS_NO_RETURN RTEMS_INLINE_ROUTINE void rtems_fatal( >> >> rtems_fatal_source fatal_source, >> >> rtems_fatal_code error_code >> >> ) >> >> { >> >> _Terminate( fatal_source, error_code ); >> >> } >> >> I suggest to move the implementation to fatal.c and remove >> RTEMS_INLINE_ROUTINE. I just don't see a benefit to implement it as >> inline. >> > > The rtems_fatal() is an API function documented in the user manual. The > _Terminate() is an internal function. > >> Besides, it has disadvantages. That is besides code size, during >> debugging, it simplifies the number of rtems_fatal symbol occurrences >> to 1. Don't have to figure out which one is which. >> > > Yes, for debugging you have to know that _Terminate() is the right function > to set the break point. This is not really great. Maybe we should remove this > indirection. > >> bsp_fatal() is another one. >> >> Phong. >> >> >> Notice: This e-mail and any files transmitted with it may >> contain Data Device Corporation's privileged and proprietary >> information. It is intended solely for the use of the >> individual or entity to whom it is addressed. If you are not >> the named recipient of this transmission, any disclosure, >> copying, distribution or reliance on the contents of this >> message is prohibited. If you received this e-mail in error, >> please destroy it and any attached files and notify me >> immediately. >> > > Do you take this message serious? > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > > Notice: This e-mail and any files transmitted with it may contain Data Device > Corporation's privileged and proprietary information. It is intended solely > for the use of the individual or entity to whom it is addressed. If you are > not the named recipient of this transmission, any disclosure, copying, > distribution or reliance on the contents of this message is prohibited. If > you received this e-mail in error, please destroy it and any attached files > and notify me immediately. > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
