<div dir="auto"><div>I think the suggestion is to provide a catch-all rather than try to add new faults for every possible condition. This mkdir is a pretty esoteric fault that is unlikely to happen in properly developed code.<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 19, 2021, 11:03 AM Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 19, 2021 at 9:48 AM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank" rel="noreferrer">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Feb 18, 2021 at 11:32 PM Sebastian Huber<br>
<<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a>> wrote:<br>
><br>
> On 18/02/2021 21:08, Gedare Bloom wrote:<br>
><br>
> >> Grrr.. I've looked again at the code and it is all Gaisler code doing something<br>
> >> like mkdir("/dev/leonXXX"). It really could fail. This should be a fatal error<br>
> >> and would seem to indicate that we need a grlib category of fatal BSP/driver<br>
> >> errors.<br>
> > Given the complexity of grlib, that would make some sense. Although<br>
> > maybe we can make it a little more generic... FATAL_THIRD_PARTY_DRIVER<br>
> > errors might be nicer on them, and can be reused<br>
> ><br>
> Maybe we should add a generic low overhead panic function. It should<br>
> uniquely identify the error source. For this we could use the return<br>
> address of a panic helper. For example:<br>
><br>
> RTEMS_NO_RETURN void rtems_game_over( void )<br>
><br>
> {<br>
><br>
>    rtems_fatal( RTEMS_GAME_OVER, (uintptr_t) __builtin_frame_address( 0 ) );<br>
><br>
> }<br>
><br>
<br>
This seems like a good idea. The name is a bit cheeky perhaps. I might<br>
suggest "unknown source" or something a little more descriptive of the<br>
condition for using this call?<br></blockquote><div><br></div><div>I don't mind a new API like this but is that the solution for the problem that</div><div>started this thread?</div><div><br></div><div>grlib calls mkdir(/dev/leonXXX) in multiple places and does not check </div><div>the return code. This is one. </div><div><br></div><div><a href="https://git.rtems.org/rtems/tree/bsps/shared/grlib/pci/gr_rasta_io.c#n577" target="_blank" rel="noreferrer">https://git.rtems.org/rtems/tree/bsps/shared/grlib/pci/gr_rasta_io.c#n577</a> </div><div><br></div><div>We have existing APIs and faults, I was just asking which one to use</div><div>in these cases.</div><div><br></div><div>--joel</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> --<br>
> embedded brains GmbH<br>
> Herr Sebastian HUBER<br>
> Dornierstr. 4<br>
> 82178 Puchheim<br>
> Germany<br>
> email: <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a><br>
> phone: +49-89-18 94 741 - 16<br>
> fax:   +49-89-18 94 741 - 08<br>
><br>
> Registergericht: Amtsgericht München<br>
> Registernummer: HRB 157899<br>
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
> Unsere Datenschutzerklärung finden Sie hier:<br>
> <a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
><br>
</blockquote></div></div>
</blockquote></div></div></div>