[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 6 Mar 2016 18:31:30 +0000
From: Hesham Almatary <heshamelmatary@...il.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com, lowrisc-dev@...ts.lowrisc.org
Subject: Re: [lowrisc-dev] musl risc-v port & gsoc - resources & ideas
Hi Rich,
Thanks for this detailed e-mail. It's worth mentioning that during my
last GSoC project that ported seL4 to RISC-V, I had to add RISC-V
support to the muslc library [1] (only 32-bit, imitating the or1k
port). It was mainly useful for userspace tasks, and works pretty
well.
I thought this might be a good starting point for anyone who might
work on this project. We can work to get this local code upstream if
that makes sense.
[1] https://github.com/heshamelmatary/musllibc
Best,
Hesham
On Fri, Mar 4, 2016 at 3:58 AM, Rich Felker <dalias@...c.org> wrote:
> lowrisc.org has been accepted into Google Summer of Code 2016, and has
> porting musl to risc-v as one of the suggested projects:
>
> http://www.lowrisc.org/docs/gsoc-2016-ideas/
>
> I'm very hopeful that we'll make the port happen this year. In this
> email I'd like to go over some resources that may be helpful to
> students interested in applying, and some ideas for other tasks that
> could be included in proposals.
>
> The musl wiki contains a porting page with some useful but
> not-entirely-up-to-date information on porting musl to a new arch.
> This is a good starting point, and updating it could actually be part
> of the gsoc project. See http://wiki.musl-libc.org/wiki/Porting
>
> Some information on recent changes can be found in the mailing list
> archives. These threads pertain to changes to how ports are expected
> to provide atomic primitives:
>
> http://www.openwall.com/lists/musl/2015/05/17/2
> http://www.openwall.com/lists/musl/2015/05/20/1
> http://www.openwall.com/lists/musl/2016/01/10/6
>
> which was committed here:
>
> http://git.musl-libc.org/cgit/musl/commit/?id=1315596b510189b5159e742110b504177bdd4932
>
> and other subsequent commits with per-arch improvements.
>
> And these cover the bits deduplication:
>
> http://www.openwall.com/lists/musl/2016/01/25/1
> http://www.openwall.com/lists/musl/2016/01/27/9
>
> which was committed here:
>
> http://git.musl-libc.org/cgit/musl/commit/?id=4dfac11538cb20c848c30d754863800061ee8c81
>
> Threads on the recent mips64 port work, which is almost ready for
> merging, may also be helpful to read. It's broken up across several
> threads but you can find most of the content in the January-March 2016
> archives.
>
> Since a port of musl to a new arch does not actually involve much
> code, mainly attention to detail to make sure that all of the type
> definitions/ABI/etc. are correct, I think that for a proposal to be
> big enough to make a reasonable GSoC project, it should go beyond just
> the basic porting. Some ideas for things to include would be:
>
> - Improvement of porting documentation
>
> - Feedback/patches on where there's too much redundancy between ports
> and how to reduce it (i.e. making improvements to musl that reduce
> the amount of code/headers needed for a new port).
>
> - Patches for musl-cross and/or musl-cross-make (build systems for
> generating a cross-compiler toolchain) to make it easy to build a
> musl/riscv cross compiler.
>
> - Optimizing performance-critical code like memcpy or floating point
> math functions for riscv.
>
> - Improving test coverage, especially for things that are easy to get
> wrong in a new port.
>
> I'll follow up with more ideas if I think of any.
>
> Students interested in the project are welcome (and encouraged!) to
> ask questions and discuss here on the musl list. Obviously everyone
> should have in mind writing their own proposals but I want everyone to
> have access to knowledge/resources/community for ideas.
>
> Rich
>
--
Hesham
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.
