rtems_fatal() as inline in a header file

[Gedare Bloom]

On Thu, May 18, 2017 at 2:35 PM, Pham, Phong <phamp at 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.huber at embedded-brains.de]
> Sent: Wednesday, May 17, 2017 10:16 PM
> To: Pham, Phong; rtems-devel at 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.huber at 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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel