Device Drivers Which Include mkdir("/dev")

Chris Johns chrisj at
Tue Feb 23 20:51:51 UTC 2021

On 24/2/21 2:18 am, Joel Sherrill wrote:
> On Tue, Feb 23, 2021 at 2:52 AM Daniel Hellstrom <daniel at
> <mailto:daniel at>> wrote:
>     I think the main reason why the mkdir() is called in the first place, from
>     for example rasta-io driver, is that once other drivers register their
>     device pciN.devM into the /dev/pciboardN/devM it would fail if the the
>     directory /dev/pciboardN has not been created. So it is an attempt to avoid
>     mkdir() in all IO drivers and move themkdir() dependency up to the pciboardN
>     driver instead. An alternative approach could be that
>     rtems_io_register_name("/dev/pciboardN/devM") would actually make sure that
>     /dev/pciboardN directory is created if does not exist? or by introducing a
>     new supporting function rtems_io_register_name_dircreat()? However, I
>     suppose that would mean we would drag in mkdir() routines in all cases even
>     when the IO drivers are only registering devices directly under /dev/ which
>     is the most common case.
> I don't like adding another method especially since you 
> would have to parse the device name to find a subdirectory
> and that just adds complication. And all that logic ends up in the
> minimum BSP footprint for using a device. 
> I started this discussion wanting a fatal error and now I am happy just 
> adding _Assert_Unused_variable_equals().  If the directory doesn't end up
> getting created, the mknod on the device will fail a few lines down so 
> there will be a failure. 

I think there is an architectural issue we need to resolve about how a root file
system is created and what we would like to see in it. The scattered approach we
use is showing its age and the issue Joel has raised is an example.

There are a couple of root file systems (maybe more):

1. None, leave it to the application

2. Standard. Creates /etc, /etc/passwd, /etc/group and /dev.

I think we should remove all the mkdir's and move this responsibility to
confdefs.h and/or the application. It will help in standardising the RTEMS file
system layout. I would use SYSINT to manage the set up so we know the layout is


More information about the devel mailing list