Device Drivers Which Include mkdir("/dev")

Chris Johns chrisj at
Sat Feb 20 19:31:31 UTC 2021

On 21/2/21 5:29 am, Gedare Bloom wrote:
> On Fri, Feb 19, 2021 at 5:26 PM Joel Sherrill <joel at> wrote:
>> On Fri, Feb 19, 2021, 5:32 PM Chris Johns <chrisj at> wrote:
>>> On 20/2/21 7:56 am, Joel Sherrill wrote:
>>>> On Fri, Feb 19, 2021 at 2:51 PM Gedare Bloom <gedare at
>>>> <mailto:gedare at>> 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?
>>> Will the call ever fail in production? Could a user configure RTEMS in a manner
>>> that generates the failure?
>>>> 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.
>>> I would not step out as far as utterly broken but yes I see your point. There
>>> are other places where we have taken this approach.
>>> If the lack of making a directory in GRLIB is handled by errors in the other
>>> dependent calls then why not add some documentation to the BSP.
>> Confirmation appreciated but it is making the directory to out a device node. The device node create will fail if there isn't a directory so this will return an error.
>> Which means an assert is ok
> I think an assert that /dev exists is fine within device drivers that
> want to create device nodes on /dev. It's not their responsibility to
> create the /dev tree, right?

I agree. It means there is a system level initialisation issue. Maybe a sysint
call that is fatal is added before drivers are initialised?


More information about the devel mailing list