Re: GSoC 2015. lowRISC "Porting musl libc to RISC-V" project.

[Rich Felker <dalias@libc.org>]

On Sat, Mar 07, 2015 at 11:24:09AM +1000, Roma Titov wrote:
> Hello, musl.
> 
> My name is Roman.
> I'm this-semester-graduading (bachelor) student from Russia, and I
> think I could be the candidate for subject. (lowRISC GSoC ideas:
> http://www.lowrisc.org/docs/gsoc-2015-ideas/)

Hi Roman!

> I already have some discussion with lowRISC developers on their
> mailing list, and this message is composed from pieces of that
> conversation.
> (resending it here is, definetily, not a good idea, lowRISC archive
> is here: http://listmaster.pepperfish.net/pipermail/lowrisc-dev-lists.lowrisc.org/)
> 
> My main worry for now is that I can't reach Rich Felker (dalias at
> libc.org) who is a mentor for this project. I wrote directy to him
> few days ago, and lowRISC devs CCed our conversation to him, but I
> didn't get any reply yet.

Sorry for not getting back to you sooner. I haven't been associated
with lowRISC in the past and I'm coming in as a potential mentor for
this GSoC project, so I was still trying to figure out what answers to
give you.

> So here's a little about my background:
> * Studying at Far East Federal University (Russia, Vladivostok, UTC
> +10).
> * My main interests in CS is HW-SW interaction (and so OSes and system
> programming) and software architecture engineering.
> * My evaluation work is autonomous surface vehicle project (it's
> software part in particular).
> At the moment I'm working on different math stuff and playing with RPi
> and ROS. Also have very rough Arduino-based prototype of inertial
> navigation system.
> * Have smth like ~5 years of Linux-user expirience. Can build kernel,
> write makefiles and CMakeLists. Know how to use VCS (git, mostly).
> Have a set of
> books and stupid university tasks behind my back.
> * As far, as I understand, I'll deal with lots of C code and,
> probably, ASM code. Well, C is OK. Had tiny ASM practice, but I
> understands concepts pretty well, I think.

In terms of code that's needed for porting musl, the arch-specific
code is mostly asm. Musl follows a principle of requiring only a very
minimal amount of arch-specific code, and in terms of actual lines of
source, ports generally consist of more lines of headers defining the
rigth types/macro constants/structures for the arch (matching the
kernel API/ABI) than lines of code.

Of course there's an opportunity to provide optimized asm for key
functions like memcpy that are likely to be bottlenecks, but we
usually only want to do this if the asm is measurably better than what
the C code compiles so. So for this type of thing you might end up
writing asm just to see if you can get it faster; even if not, that's
a worthwhile finding to have.

From my past experience helping people with ports, the biggest amount
of time is spent not on writing code, but on understanding ABI
intricacies, syscall calling convention and arch-specific kernel
quirks, etc. and just getting a good working environment bootstrapped
to test on.

> I read through the porting-to-new-arch docs on musl wiki
> (http://wiki.musl-libc.org/wiki/Porting) and looked through musl
> sources.
> (offtopic: omg, musl-devs are the best, not all project I've seen so
> far have such simple and easy get-into-problem guides)

:-)

> As I read Tanenbaum's "Computer Architecture" carefully, I think I
> fully understand this porting guide and so my further steps and my
> proposal would be based on it.
> Not to mention, I found musl project most mature among other GSoC
> projects I'm interested and feel more and more thrilled about
> working on it. :)
> 
> For now I'm a little bit worried about signals and pthreads, as it
> is most complex part (I think) and I don't *fully* grok *internal*
> mechanisms of synchronization *yet*.
> Any advices and any help in this area would be greatly appreciated.

Thankfully you don't need to understand how all the existing code in
musl works as long as you can implement a few simple asm functions
needed for these components to work. But in the process of
implementing them, you might find yourself asking why they need to do
what they do, and in the process come to understand the big picture.
:-)

In terms of putting together your proposal, I think Justin Cormack's
remarks (off-list) about writing a simple program making one or more
system calls in inline asm (or an asm source file) in RISC-V assembly
would be a good exercise and a good start for demonstrating your
ability to work on this project.

Rich