x86_64 port and BSP (GSoC 2018)

Sat Mar 17 18:09:35 UTC 2018

On Sat, Mar 17, 2018 at 11:58 AM, Amaan Cheval <amaan.cheval at gmail.com> wrote:
> 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?
>

It does. I think Phase 3 remains light. I'd encourage you to flesh out
the plan for one of the "bonus" areas for this phase. That way, if you
reach it, you will be prepared to undertake it without having to think
too hard about the design aspects.

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

Some do.

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

The reason I suggest Joel might look is because touching GCC code is a
bit of a hassle (the first time).

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