<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 23, 2021 at 2:52 AM Daniel Hellstrom <<a href="mailto:daniel@gaisler.com">daniel@gaisler.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi,</p>
<p>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.<br></p></div></blockquote><div><br></div><div>I don't like adding another method especially since you </div><div>would have to parse the device name to find a subdirectory</div><div>and that just adds complication. And all that logic ends up in the</div><div>minimum BSP footprint for using a device. </div><div><br></div><div>I started this discussion wanting a fatal error and now I am happy just </div><div>adding _Assert_Unused_variable_equals(). If the directory doesn't end up</div><div>getting created, the mknod on the device will fail a few lines down so </div><div>there will be a failure. </div><div><br></div><div>--joel</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
</p>
<p>Daniel</p>
<div>
<pre>
</pre>
</div>
<div>On 2021-02-20 20:31, Chris Johns wrote:<br>
</div>
<blockquote type="cite">
<pre>On 21/2/21 5:29 am, Gedare Bloom wrote:
</pre>
<blockquote type="cite">
<pre>On Fri, Feb 19, 2021 at 5:26 PM Joel Sherrill <a href="mailto:joel@rtems.org" target="_blank"><joel@rtems.org></a> wrote:
</pre>
<blockquote type="cite">
<pre>On Fri, Feb 19, 2021, 5:32 PM Chris Johns <a href="mailto:chrisj@rtems.org" target="_blank"><chrisj@rtems.org></a> wrote:
</pre>
<blockquote type="cite">
<pre>On 20/2/21 7:56 am, Joel Sherrill wrote:
</pre>
<blockquote type="cite">
<pre>On Fri, Feb 19, 2021 at 2:51 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>
<a href="mailto:gedare@rtems.org" target="_blank"><mailto:gedare@rtems.org></a>> 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?
</pre>
</blockquote>
<pre>Will the call ever fail in production? Could a user configure RTEMS in a manner
that generates the failure?
</pre>
<blockquote type="cite">
<pre>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.
</pre>
</blockquote>
<pre>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.
</pre>
</blockquote>
<pre>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.
<a href="https://git.rtems.org/rtems/tree/bsps/shared/grlib/pci/gr_rasta_io.c#n577" target="_blank">https://git.rtems.org/rtems/tree/bsps/shared/grlib/pci/gr_rasta_io.c#n577</a>
Which means an assert is ok
</pre>
</blockquote>
<pre>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?
</pre>
</blockquote>
<pre>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
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>
<a href="http://lists.rtems.org/mailman/listinfo/devel" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a>
</pre>
</blockquote>
</div>
</blockquote></div></div>