<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 11, 2016 at 8:17 AM, Sebastian Huber <span dir="ltr"><<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
----- Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> schrieb:<br>
<span class="">> On 8/04/2016 7:34 PM, Sebastian Huber wrote:<br>
> > On 08/04/16 11:22, Chris Johns wrote:<br>
> >>> I don't think its feasible to avoid <rtems/confdefs.h>. Its now the only<br>
> >>> way to create a configuration.<br>
> >>><br>
> >><br>
> >> Sorry, but I do not like confdefs getting these values in this way.<br>
> >> This is not a great long term solution. Easy to add very hard to remove.<br>
> >><br>
> >> Maybe you need make some score level variables and compute the values<br>
> >> during configuration.<br>
> ><br>
> > In this case they are no longer read-only.<br>
><br>
> Yes and holding RAM base computed values does use a couple of ints. Is<br>
> there another reason they need to be read only?<br>
<br>
</span>On BSP with MMU you get an exception if you modify them.<br>
<br>
For cache efficiency its better to put read-only data in the same cache lines.<br>
<br>
If you put related values into one structure then you only have to load the structure base address once and can re-use the register containing the address in subsequent load/store operations.<br>
<span class=""><br>
><br>
> This change exposes implementation details unrelated to the<br>
> configuration table. I cannot see a way we can avoid this with out<br>
> having internal intermediate values. What is being proposed is an<br>
> optimization and one worth doing but it exposes an optimization detail<br>
> in an unfortunate way. If the implementation changes and these values<br>
> are no longer needed can we remove them? We have no control on who uses<br>
> them once we add them.<br>
<br>
</span>I use RTEMS since 2008 and never created my own configuration table. From my point of view the user level API is<br>
<br></blockquote><div><br></div><div>confdefs.h came about because when there were already 50-100 tests, manually creating</div><div>and maintaining them was a real pain. Any change in the structures had to be propagated</div><div>manually to all tests. Every test set every field and it was impossible to know which fields</div><div>were really of interest to a test.</div><div><br></div><div>Eventually users started using confdefs.h and it moved from a test fixture to a user aid.</div><div>That resulted in much more attention to the formulas for memory allocation and the need</div><div>for it to cover more configuration parameters. Plus be relatively easy to explain.</div><div><br></div><div><div> Around 4.9 or 4.10, we began to assume the names of the</div><div>various data structures.</div></div><div><br></div><div>The past couple of classes I have taught, I have wondered if it is time to delete the </div><div>"has own table" options. We wouldn't recommend it and wouldn't want to help</div><div>someone debug it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
#define CONFIGURE_MICROSECONDS_PER_TICK 123<br>
<br>
#include <rtems/confdefs.h><br>
<br>
and<br>
<br>
#include <rtems.h><br>
<br>
void f(void)<br>
{<br>
  uint32_t upt = rtems_configuration_get_microseconds_per_tick();<br>
}<br>
<br>
What RTEMS does with the configuration input an how it delivers the value via rtems_configuration_get_microseconds_per_tick() should be of no concern for the application developer.<br>
<span class=""><br></span></blockquote><div><br></div><div>That's a general statement which applies to every operation. But whether it is a macro, value,</div><div>or method should be irrelevant to a user.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
><br>
> ><br>
> > One way to test it would be to use<br>
> ><br>
> > #define CONFIGURE_MICROSECONDS_PER_TICK 1000000000<br>
> ><br>
> > and exploit the limited integer ranges. Doesn't work if we check this<br>
> > configuration error in <rtems/confdefs.h>.<br>
> ><br>
><br>
> A concern for me is the separation of the definition and the management.<br>
> As a compromise maybe documenting the fields as generated would help and<br>
> then provide a macro in the configuration table header to set the user<br>
> visible value which then sets the generated values.<br>
><br>
> I would prefer not to pollute the table.<br>
><br>
> Chris<br>
<br>
</span>We should not rely on <rtems/confdefs.h> to do the right things. So, a run-time check resulting in a fatal error is desirable. I will try to find a solution which is testable.  Otherwise, we can keep the things as is, since its only a micro optimization.<br>
<span class=""><br></span></blockquote><div><br></div><div>There is the option of error checking via macros in confdefs.h. That isn't a bad line of defense either.</div><div>Stops things at compile time.</div><div><br></div><div>Ultimately we have to rely on something to do the right thing. What errors are you two worried about</div><div>that couldn't happen now?</div><div><br></div><div>--joel</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
--<br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone   : <a href="tel:%2B49%2089%20189%2047%2041-16" value="+4989189474116">+49 89 189 47 41-16</a><br>
Fax     : <a href="tel:%2B49%2089%20189%2047%2041-09" value="+4989189474109">+49 89 189 47 41-09</a><br>
</span>E-Mail  : sebastian.huber at <a href="http://embedded-brains.de" rel="noreferrer" target="_blank">embedded-brains.de</a><br>
<span class="im">PGP     : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
</span><div class=""><div class="h5">_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></div></div></blockquote></div><br></div></div>