[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA-4+jcCvV03oxCqNYoGsLtiz=Bcj=RfssJUfrx_V_A1N5Qe=w@mail.gmail.com>
Date: Sun, 20 Mar 2016 12:13:43 +0900
From: Masanori Ogino <masanori.ogino@...il.com>
To: Rich Felker <dalias@...c.org>
Cc: lowrisc-dev@...ts.lowrisc.org, musl@...ts.openwall.com
Subject: Re: [GSoC2016] A proposal on porting musl to RISC-V
Thank you for reviewing!
2016-03-19 15:37 GMT+09:00 Rich Felker <dalias@...c.org>:
> Looks very good! Some comments:
>
> In regards to your schedule, do you plan to do both rv32 and rv64 (and
> some 'subarch' ABI variants for both) in parallel from the beginning?
> I think it might make sense to get one (whatever is easiest) to the
> point where you can do some meaningful testing before working on them
> all, but I'd be happy to hear your thoughts on what approach works
> best for you.
Yes, I planed to port 32-bit and 64-bit variant in parallel. However,
now I think that porting one first and then doing the other is better
since this approach can test the toolchain part earlier.
> One thing to keep in mind (not sure if you're aware of it yet) is that
> there's an in-progress port, now linked from the lowrisc.org project
> ideas page, by another student who's interested in applying. Please
> don't be discouraged by that; the reason I'm mentioning it is just
> that I think anyone applying should either be planning to use the work
> that's already done (being careful to properly document authorship) or
> have a good explanation for why they're not going to. For your
> proposal, this probably means greatly reducing the number of weeks to
> be spent on getting the port basically up and running and dedicating
> more time to the extended deliverables.
I didn't aware of that port. Thanks!
I will take a look at it and revise the proposal with my decision.
> That's actually a good thing because I don't think you've allocated as
> much time for the extended deliverables as they might take. For
> example, for the vdso stuff, if you plan to do the actual kernel
> patches, that's going to require familiarizing yourself with kernel
> hacking if you're not already. And hooking it up to GCC for the
> compiler to use with -mno-atomic (rather than just having libc use it
> internally) requires some GCC hacking _and_ establishing some ABI for
> the GCC-generated code to get to the vdso (probably via libc).
Sure. I will reconsider the schedule.
> Hope these comments help, and sorry for not getting back to you
> sooner. I've had a busy week.
No problem. This really helps me.
--
Masanori Ogino
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
