[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160319063749.GT21636@brightrain.aerifal.cx>
Date: Sat, 19 Mar 2016 02:37:49 -0400
From: Rich Felker <dalias@...c.org>
To: Masanori Ogino <masanori.ogino@...il.com>
Cc: lowrisc-dev@...ts.lowrisc.org, musl@...ts.openwall.com
Subject: Re: [GSoC2016] A proposal on porting musl to RISC-V
On Wed, Mar 16, 2016 at 10:22:31AM +0900, Masanori Ogino wrote:
> Hello,
>
> I published an early draft of my Google Summer of Code 2016 proposal.
> You can get the draft from:
> https://github.com/omasanori/gsoc2016-proposal .
>
> Check https://github.com/omasanori/gsoc2016-proposal/releases/tag/rev1
> if you want a PDF file of this revision.
>
> Any comment would be appreciated. Feel free to send comments on MLs or GitHub.
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.
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.
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).
Hope these comments help, and sorry for not getting back to you
sooner. I've had a busy week.
Rich
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.
