On Tue, Feb 23, 2021 at 2:52 AM Daniel Hellstrom <dan...@gaisler.com> wrote:
> Hi,
>
> 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.
--joel
> Daniel
>
> On 2021-02-20 20:31, Chris Johns wrote:
>
> On 21/2/21 5:29 am, Gedare Bloom wrote:
>
> On Fri, Feb 19, 2021 at 5:26 PM Joel Sherrill <j...@rtems.org>
> <j...@rtems.org> wrote:
>
> On Fri, Feb 19, 2021, 5:32 PM Chris Johns <chr...@rtems.org>
> <chr...@rtems.org> wrote:
>
> On 20/2/21 7:56 am, Joel Sherrill wrote:
>
> On Fri, Feb 19, 2021 at 2:51 PM Gedare Bloom
> <ged...@rtems.org<mailto:ged...@rtems.org> <ged...@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?
>
> 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.
> https://git.rtems.org/rtems/tree/bsps/shared/grlib/pci/gr_rasta_io.c#n577
>
> 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?
>
> Chris
> _______________________________________________
> devel mailing listdevel@rtems.orghttp://lists.rtems.org/mailman/listinfo/devel
>
>
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
