x86_64 port and BSP (GSoC 2018)

Sat Mar 17 15:58:01 UTC 2018

First off, thank you so much for the prompt and detailed response! I really
appreciate the help!

On Sat, Mar 17, 2018 at 6:46 PM Gedare Bloom <gedare at rtems.org> wrote:

> On Sat, Mar 17, 2018 at 2:24 AM, Amaan Cheval <amaan.cheval at gmail.com>
wrote:
> > Hey everyone!
> >
> > Here's a link to a draft of my proposal (also shared through the GSoC
> > website, and linked to on the wiki):
> >
https://docs.google.com/document/d/1X79Yj0DNqvaDFqpJMUX4gF3WC550GDvVDS5QufvAnFE/edit?usp=sharing
> >
> > I'd appreciate all comments - even if you're just skimming, let me know
if
> > you have something to say!
> >
> > I have a few questions too, which I'd appreciate help with:
> >
> > Regarding the proposal:
> >
> > - Does it seem like I'm committing too little / too much?

> I don't think you have work planned in a good way. The scope of the
> second half is light, while the first half may be heavy. It is OK to
> have schedule slip, but it is better if you can try to balance the
> work over the phases. Also, note that GSoC is now a three-thirds
> instead of two-halves timeline.

Noted. I've revised it a bit (same link). Would you mind having another
look?

> > - Are there any issues I've completely overlooked? Something I've
> > oversimplified / that I may not realize the scope / difficulty of?

> Getting boot to work properly may be harder than you anticipate.

That's a good point. I've made the target for phase 1 about getting stub
code there, boot/init code started, and patching the x86_64 tools up to
have them be feature-complete. (It's hard to gauge if that's a satisfactory
goal given that I'm not quite sure of the current status of the tools -
this is why I'm hoping to resolve this ASAP.)

Would you let me know if the deliverables seem more evenly distributed and
realistic now?

> Doing the ISR right means implementing the APIC support in a proper way.
> I think it will be a good idea for you to address SMP issues together
> with the UP implementation.

I agree, but I'd rather not commit to SMP support since that sounds like it
might be too much - I can't know that, of course, but I think I'd rather
keep it a bonus activity that I'll be able to pull in when I'm more in the
swing of things and better able to gauge the effort required.

> > - It seems like Chris (cc'd) owns the x86_64 ticket - would Chris be a
> > potential mentor, or is ticket ownership not indicative of who the
mentor
> > might be?

> Yes, Chris or Joel are likely mentors, unless another interested party
pops up.

I see! Do mentors usually mentor more than one student?

> >
> > Misc:
> >
> > - I noticed that this project has been proposed in the past, at least
> > twice. Is there any constructive criticism from the proposals back then
> > that I could learn from?

> Not really. The previous proposals were weak, and this project was not
> a high priority back then.

Ah. Is there anything I can do to strengthen my proposal, in that case,
besides the feedback you've already provided? I do already plan to tackle
more tickets as time permits / get a head start on fixing / verifying the
x86_64 tools up. Is there anything else I should also be doing? Any other
resources I should be looking at?

I just want to make sure that I know what I'm getting into and that you
guys aren't making a blind bet - anything I can do to prove to you and me
that I'm actually capable of handling this task would be immensely helpful.

> > - In the proposals, I've left some tasks about the x86_64 rtems-tools
> > highlighted in red because I'm hoping to test the tools before the
proposal
> > deadline to have a clearer idea for the timeline. The ticket[1] lists
some
> > tasks regarding the tools, but I'm not sure what the status of them is
yet,
> > or how to carry the tasks out quite yet. I aim to tackle this as soon as
> > possible, but if you can provide any guidance, I'd appreciate that.
> >

> The x86_64 tools have a recipe in RSB, you can give it a try. The
> tasks identified there are in two categories:
> 1. GCC multilib support for FPU -- You should ask Joel to look into
> this for you. :)

@Joel (cc'd) would you mind doing this? If you're busy / don't want to
(:P), would you mind letting me know how I can do it myself?

I'd like to dig into the tools as soon as possible because it seems like it
has the potential to significantly influence my timeline for this project,
and knowing in advance I'll be better equipped to commit the right amount.

> 2. Newlib support for setjmp/longjmp, and anything else that should be
> in the libc. You should do this. Join newlib mailing list, check out
> the source, and find the current i386 and x86_64 implementations.
> (Hint: newlib.git/newlib/libc/machine/[i386 x86_64]).
> 3. TLS. There are multiple ways to implement it. I don't know what is
> preferred for this. See https://www.akkadia.org/drepper/tls.pdf for a
> thorough background.

Thank you for the detailed resources! I'll add them to the project ticket
as well for future reference.

P.S. - I'd also like to say congrats to all the maintainers for having such
a splendid community! It feels great to be a part of such a healthy
open-source ecosystem!

> > Thanks!
> >
> > [1] https://devel.rtems.org/ticket/2898#Tools
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel