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

[Gedare Bloom]

On Mon, Mar 12, 2018 at 12:41 PM, Amaan Cheval <amaan.cheval at gmail.com> wrote:
> 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?
>

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