<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 12, 2018 at 3:20 PM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Mar 12, 2018 at 12:41 PM, Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a>> wrote:<br>
> On Mon, Mar 12, 2018 at 9:53 PM Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br>
><br>
>> On Mon, Mar 12, 2018 at 3:01 AM, Sebastian Huber<br>
>> <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-<wbr>brains.de</a>> wrote:<br>
>> > On 10/03/18 18:02, Amaan Cheval wrote:<br>
>> >><br>
>> >> - Improve RTEMS SMP[3]<br>
>> >><br>
>> >> What kinds of improvements to SMP are we considering?<br>
>> ><br>
>> ><br>
>> > The SMP support is quite complete now. In general, an independent<br>
> review is<br>
>> > required, but this is probably not a GSoC project. Some areas in the<br>
>> > implementation are a bit too complex (e.g. thread lock) and should be<br>
>> > simplified, however, I guess this is a very difficult task.<br>
>> ><br>
>> > A formal specification using TLA+ for the OMIP and MrsP locking<br>
> protocols<br>
>> > would be nice.<br>
>> ><br>
>> > <a href="https://en.wikipedia.org/wiki/TLA%2B" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/<wbr>TLA%2B</a><br>
>> ><br>
>> > A proper strong APA scheduler:<br>
>> ><br>
>> > <a href="https://devel.rtems.org/ticket/2510" rel="noreferrer" target="_blank">https://devel.rtems.org/<wbr>ticket/2510</a><br>
>> ><br>
>> > I am not sure if there is a real application demand for this.<br>
>> ><br>
><br>
>> I would be supportive of formal specification or strong APA projects<br>
>> despite user demand.<br>
><br>
> That's good to know! I'll look into it! :)<br>
><br>
><br>
>> >> As noted earlier, SMP<br>
>> >> support on i386 is lagging. Is there any interest in bringing that up<br>
> to<br>
>> >> par with the other architectures?<br>
>> ><br>
>> ><br>
>> > I think this makes only sense for a x86_64 BSP.<br>
>> ><br>
><br>
>> There is a need for a modernized framework for x86 and x86_64. Both<br>
>> projects are relevant and important.<br>
><br>
> That's good to know. I haven't been able to quite tease the 2 projects<br>
> apart; for eg. it seems the x86_64 BSP would also be based on non-legacy<br>
> hardware (UEFI vs. BIOS?), so it would be tied to improving the existing<br>
> PC386 code as well.<br>
><br>
> I think my main proposal will be along these lines; figuring out the<br>
> essentials for the x86_64 BSP, and modernizing the existing x86 as I can at<br>
> the same time.<br>
><br>
> How does that sound?<br>
><br>
<br>
</div></div>I think that should be appropriate. You should be able to demonstrate<br>
progress on the new BSP then, while you contribute code to the old<br>
one.<br></blockquote><div><br></div><div>When Chris and I have discussed this in the past, we have tossed around</div><div>the idea of a new port -- x86_64,. a true 64-bit port. It would have a new</div><div>BSP that would not depend on legacy hardware and would boot using UEFI.</div><div><br></div><div>To pace this out so it is achievable in a summer, the first steps would</div><div>focus on the port proper and do the minimum required of a BSP to get</div><div>it running on qemu. Real HW would be a sanity check. Focus on a port</div><div>and minimum BSP (initialization, console, clock tick). </div><div><br></div><div>Chris has suggested that the BSP could use whatever it needed from</div><div>FreeBSD, such as UEFI support.</div><div><br></div><div>Key.. new port.. new BSP.. without the legacy baggage of 32-bit and old HW.</div><div>More work but a much better result in the long run.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> Since I'm pretty keen on RTEMS, I think I'll have a 2nd proposal too, which<br>
> I'll decide and discuss with you guys soon, hopefully! (Perhaps the tracing<br>
> or the APA scheduling projects).<br>
><br>
<br>
</span>That's fine.  I don't think APA by itself is enough for the summer.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
>> > From an application developer point of view a ready to use tracing of<br>
> thread<br>
>> > context switches and interrupts would be nice. Some kind of data<br>
> provider<br>
>> > for the lttng-relayd (LTTng 2 relay daemon)<br>
>> ><br>
>> > <a href="https://lttng.org/docs/v2.10/#doc-lttng-relayd" rel="noreferrer" target="_blank">https://lttng.org/docs/v2.10/#<wbr>doc-lttng-relayd</a><br>
>> ><br>
>> > Which can be used by<br>
>> ><br>
>> > <a href="https://projects.eclipse.org/projects/tools.tracecompass" rel="noreferrer" target="_blank">https://projects.eclipse.org/<wbr>projects/tools.tracecompass</a><br>
>> ><br>
><br>
>> Joel has been looking at the trace compass. We also have other tracing<br>
>> projects (barectf integration) that would be relevant to investigate<br>
>> along those same lines.<br>
><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">+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>
>> > E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-<wbr>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>
>> ><br>
>> > ______________________________<wbr>_________________<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/<wbr>mailman/listinfo/devel</a><br>
______________________________<wbr>_________________<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/<wbr>mailman/listinfo/devel</a></div></div></blockquote></div><br></div></div>