Device Drivers Which Include mkdir("/dev")

Gedare Bloom gedare at rtems.org
Fri Feb 19 20:51:14 UTC 2021


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.

On Fri, Feb 19, 2021, 11:03 AM Joel Sherrill <joel at rtems.org> wrote:

>
>
> On Fri, Feb 19, 2021 at 9:48 AM Gedare Bloom <gedare at rtems.org> wrote:
>
>> On Thu, Feb 18, 2021 at 11:32 PM Sebastian Huber
>> <sebastian.huber at 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.huber at 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/
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210219/bb0cee87/attachment.html>


More information about the devel mailing list