On Fri, Feb 19, 2021 at 9:48 AM Gedare Bloom <ged...@rtems.org> wrote:
> 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?
>
I don't mind a new API like this but is that the solution for the problem
that
started this thread?
grlib calls mkdir(/dev/leonXXX) in multiple places and does not check
the return code. This is one.
https://git.rtems.org/rtems/tree/bsps/shared/grlib/pci/gr_rasta_io.c#n577
We have existing APIs and faults, I was just asking which one to use
in these cases.
--joel
>
> > --
> > 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
