<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 26, 2016 at 10:02 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 26/01/16 16:51, Joel Sherrill wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi<br>
<br>
I have questions that probably impact all/most of the patches so thought I would start another thread. Then it is just detailed review of the individual patches.<br>
<br>
+ We have used EXTERN to avoid duplicating extern and instantiating data. You appear to have completely removed that pattern with no discussion of changing the coding style. I really don't like duplication of the information.<br>
</blockquote>
<br></span>
There is no duplicate information. We have exactly one declaration and one definition. The compiler checks that they harmonize. Its necessary to move the definitions to the right module, so that the linker can do its job and add the right initialization items.<br>
<br></blockquote><div style="">It was formerly one line that did both in a single location with documentation. The data was instantiated in a per manager file. The pattern was clear since it was used at least twenty times.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This extern stuff is not mentioned here:<br>
<br>
<a href="https://devel.rtems.org/wiki/Developer/Coding/Conventions" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/Developer/Coding/Conventions</a><span class=""><br>
<br></span></blockquote><div><br></div><div style="">Come on.. citing letter of the "law" in this case is a pretty weak defense. There is a lot of stuff not mentioned there and you have been around long enough to know that that particular document has been grown a bit at a time specifically as we realized there is a pattern not covered. You and I both know that it is likely far from complete. And using "not mentioned" when there is clearly an existing pattern in the code itself is disingenuous.</div><div style=""><br></div><div style="">What a compiler may check and duplicating information are different things. You have changed the pattern in at least two ways:</div><div style=""><br></div><div style="">+ dedicated file for data instantiation per manager/handler</div><div style="">+ single line to serve both as declaration and instantiation </div><div style=""><br></div><div style="">The two patterns have similar technical effect in that they declare and instance a variable. But you changed the pattern with no discussion about the pattern. That is the issue here.</div><div style=""><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
+ Do you have any size metrics for current --disable-posix on a BSP with function sections enabled versus this new way?<br>
</blockquote>
<br></span>
No, I was not interested in this comparison since my goal is to always enable POSIX in the long run. The size will drop a bit. I used the SIS BSP for comparison since it uses the function/data sections for quite a while.<span class=""><br>
<br></span></blockquote><div style=""><br></div><div style="">OK. Although not 100% accurate, comparing test sizes from 4.11 with POSIX on and master with POSIX on should give an indication of the impact. This type of comparison has been more than adequate to show how other things that impact code size have worked out. We know the core capabilities required by each test haven't changed. What happened to its footprint between two release points is an important measure.</div><div style=""><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
+ What impact does this have on BSP linkcmds? I am guessing since you already added all the rtems sysinit magic, this will just work with no issues. And we are stuck with missing function section KEEP's.<br>
</blockquote>
<br></span>
The linkcmds relevant patch sets are these and they are in place since September 2015:<br>
<br>
<a href="https://git.rtems.org/rtems/commit/?id=d0c39838146c6a186ddda3d95dac71c3fa90f11e" rel="noreferrer" target="_blank">https://git.rtems.org/rtems/commit/?id=d0c39838146c6a186ddda3d95dac71c3fa90f11e</a><br>
<a href="https://git.rtems.org/rtems/log/?qt=range&q=b618d8cfc54f84d4ed03dc7b7fa510c872e6128a" rel="noreferrer" target="_blank">https://git.rtems.org/rtems/log/?qt=range&q=b618d8cfc54f84d4ed03dc7b7fa510c872e6128a</a><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br></span></blockquote></blockquote><div style="">That's what I thought. It was just a double check.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Not opposed to doing the sysinit. I would just like to know what the size delta is between the two solutions. I am guessing this and function sections will be consistently smaller as compared to when POSIX is currently enabled.<br>
<br>
--joel<br>
<br>
<br></span>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">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><span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
-- <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" target="_blank">+49 89 189 47 41-16</a><br>
Fax : <a href="tel:%2B49%2089%20189%2047%2041-09" value="+4989189474109" target="_blank">+49 89 189 47 41-09</a><br>
E-Mail : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
PGP : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
<br>
</font></span></blockquote></div><br></div></div>