On Thu, Feb 18, 2021 at 11:32 PM Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:
>
> On 18/02/2021 21:08, Gedare Bloom wrote:
>
> >> Grrr.. I've looked again at the code and it is all Gaisler code doing
> >> something
> >> like mkdir("/dev/leonXXX"). It really could fail. This should be a fatal
> >> error
> >> and would seem to indicate that we need a grlib category of fatal
> >> BSP/driver
> >> errors.
> > Given the complexity of grlib, that would make some sense. Although
> > maybe we can make it a little more generic... FATAL_THIRD_PARTY_DRIVER
> > errors might be nicer on them, and can be reused
> >
> Maybe we should add a generic low overhead panic function. It should
> uniquely identify the error source. For this we could use the return
> address of a panic helper. For example:
>
> RTEMS_NO_RETURN void rtems_game_over( void )
>
> {
>
> rtems_fatal( RTEMS_GAME_OVER, (uintptr_t) __builtin_frame_address( 0 ) );
>
> }
>
This seems like a good idea. The name is a bit cheeky perhaps. I might
suggest "unknown source" or something a little more descriptive of the
condition for using this call?
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax: +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
