GSoC 2018 (x86_64, pc386, SMP improvements, rump kernels)

[Amaan Cheval]

On Mon, Mar 12, 2018 at 9:53 PM Gedare Bloom <gedare at rtems.org> wrote:

> On Mon, Mar 12, 2018 at 3:01 AM, Sebastian Huber
> <sebastian.huber at 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.huber at embedded-brains.de
> > PGP     : Public key available on request.
> >
> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> >
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel