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.
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> 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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
