On Mon, Mar 12, 2018 at 12:41 PM, Amaan Cheval <amaan.che...@gmail.com> wrote: > On Mon, Mar 12, 2018 at 9:53 PM Gedare Bloom <ged...@rtems.org> wrote: > >> On Mon, Mar 12, 2018 at 3:01 AM, Sebastian Huber >> <sebastian.hu...@embedded-brains.de> wrote: >> > On 10/03/18 18:02, Amaan Cheval wrote: >> >> >> >> - Improve RTEMS SMP[3] >> >> >> >> What kinds of improvements to SMP are we considering? >> > >> > >> > The SMP support is quite complete now. In general, an independent > review is >> > required, but this is probably not a GSoC project. Some areas in the >> > implementation are a bit too complex (e.g. thread lock) and should be >> > simplified, however, I guess this is a very difficult task. >> > >> > A formal specification using TLA+ for the OMIP and MrsP locking > protocols >> > would be nice. >> > >> > https://en.wikipedia.org/wiki/TLA%2B >> > >> > A proper strong APA scheduler: >> > >> > https://devel.rtems.org/ticket/2510 >> > >> > I am not sure if there is a real application demand for this. >> > > >> I would be supportive of formal specification or strong APA projects >> despite user demand. > > That's good to know! I'll look into it! :) > > >> >> As noted earlier, SMP >> >> support on i386 is lagging. Is there any interest in bringing that up > to >> >> par with the other architectures? >> > >> > >> > I think this makes only sense for a x86_64 BSP. >> > > >> There is a need for a modernized framework for x86 and x86_64. Both >> projects are relevant and important. > > That's good to know. I haven't been able to quite tease the 2 projects > apart; for eg. it seems the x86_64 BSP would also be based on non-legacy > hardware (UEFI vs. BIOS?), so it would be tied to improving the existing > PC386 code as well. > > I think my main proposal will be along these lines; figuring out the > essentials for the x86_64 BSP, and modernizing the existing x86 as I can at > the same time. > > How does that sound? >
I think that should be appropriate. You should be able to demonstrate progress on the new BSP then, while you contribute code to the old one. > Since I'm pretty keen on RTEMS, I think I'll have a 2nd proposal too, which > I'll decide and discuss with you guys soon, hopefully! (Perhaps the tracing > or the APA scheduling projects). > That's fine. I don't think APA by itself is enough for the summer. > >> > From an application developer point of view a ready to use tracing of > thread >> > context switches and interrupts would be nice. Some kind of data > provider >> > for the lttng-relayd (LTTng 2 relay daemon) >> > >> > https://lttng.org/docs/v2.10/#doc-lttng-relayd >> > >> > Which can be used by >> > >> > https://projects.eclipse.org/projects/tools.tracecompass >> > > >> Joel has been looking at the trace compass. We also have other tracing >> projects (barectf integration) that would be relevant to investigate >> along those same lines. > >> > -- >> > Sebastian Huber, embedded brains GmbH >> > >> > Address : Dornierstr. 4, D-82178 Puchheim, Germany >> > Phone : +49 89 189 47 41-16 >> > Fax : +49 89 189 47 41-09 >> > E-Mail : sebastian.hu...@embedded-brains.de >> > PGP : Public key available on request. >> > >> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. >> > >> > >> > _______________________________________________ >> > 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