On 21/2/21 5:29 am, Gedare Bloom wrote: > On Fri, Feb 19, 2021 at 5:26 PM Joel Sherrill <j...@rtems.org> wrote: >> On Fri, Feb 19, 2021, 5:32 PM Chris Johns <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>> 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 list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
