From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7157 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: GSoC 2015. lowRISC "Porting musl libc to RISC-V" project. Date: Fri, 6 Mar 2015 20:41:31 -0500 Message-ID: <20150307014131.GS23507@brightrain.aerifal.cx> References: <1425691449.12789.3@smtp.gmail.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1425692527 2043 80.91.229.3 (7 Mar 2015 01:42:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 7 Mar 2015 01:42:07 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7170-gllmg-musl=m.gmane.org@lists.openwall.com Sat Mar 07 02:41:54 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YU3kX-00079O-Iz for gllmg-musl@m.gmane.org; Sat, 07 Mar 2015 02:41:53 +0100 Original-Received: (qmail 21604 invoked by uid 550); 7 Mar 2015 01:41:52 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 21553 invoked from network); 7 Mar 2015 01:41:44 -0000 Content-Disposition: inline In-Reply-To: <1425691449.12789.3@smtp.gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7157 Archived-At: 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