Device Drivers Which Include mkdir("/dev")

[Joel Sherrill]

On Fri, Feb 19, 2021 at 2:51 PM Gedare Bloom <gedare at rtems.org> wrote:

> 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.
>

Then why shouldn't this just be a debug _Assert and value not check
deliberately?

Isn't an assert something that should not happen in a properly designed
BSP. In
this case, it would be the sysinit magic that would be utterly broken.

--joel

>
> 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/a61f568e/attachment.html>