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

[Joel Sherrill]

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

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

When Chris and I have discussed this in the past, we have tossed around
the idea of a new port -- x86_64,. a true 64-bit port. It would have a new
BSP that would not depend on legacy hardware and would boot using UEFI.

To pace this out so it is achievable in a summer, the first steps would
focus on the port proper and do the minimum required of a BSP to get
it running on qemu. Real HW would be a sanity check. Focus on a port
and minimum BSP (initialization, console, clock tick).

Chris has suggested that the BSP could use whatever it needed from
FreeBSD, such as UEFI support.

Key.. new port.. new BSP.. without the legacy baggage of 32-bit and old HW.
More work but a much better result in the long run.


>
> > 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
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180312/98542f77/attachment-0002.html>