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? 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). > > 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
