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

Tue Mar 13 16:50:09 UTC 2018

I like the sound of that! One quick question.

> ...to get it running on qemu. Real HW would be a sanity check.

What kind of real hardware would I need? I do have an x86 64-bit processor
as my primary computer, and likely one on spare / abandoned devices too
(though I'll need to confirm). Is there anything specific that you foresee
me needing to check to confirm they'll be good enough for the purposes of
this project (besides UEFI)?

I also vaguely remember OAR hosting a lab with a bunch of development
boards; does the lab have x86_64 hardware?

On Tue, Mar 13, 2018 at 2:04 AM Joel Sherrill <joel at rtems.org> wrote:

> 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