From mboxrd@z Thu Jan 1 00:00:00 1970 From: ng0@crash.cx Subject: Re: GSoC Date: Thu, 08 Feb 2018 12:31:32 +0000 Message-ID: <876077oe6z.fsf@abyayala.i-did-not-set--mail-host-address--so-tickle-me> References: <87bmh4qrf5.fsf@abyayala.i-did-not-set--mail-host-address--so-tickle-me> <87bmh3kbd9.fsf@gnu.org> <87k1vqv23v.fsf@abyayala.i-did-not-set--mail-host-address--so-tickle-me> <87r2pv67vv.fsf@abyayala.i-did-not-set--mail-host-address--so-tickle-me> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35754) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ejlMb-0000SK-NC for guix-devel@gnu.org; Thu, 08 Feb 2018 07:31:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ejlMW-0005fo-FB for guix-devel@gnu.org; Thu, 08 Feb 2018 07:31:39 -0500 Received: from aibo.runbox.com ([91.220.196.211]:57722) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ejlMW-0005f1-7J for guix-devel@gnu.org; Thu, 08 Feb 2018 07:31:36 -0500 Received: from [10.9.9.211] (helo=mailfront11.runbox.com) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1ejlMU-0007Xn-Cb for guix-devel@gnu.org; Thu, 08 Feb 2018 13:31:34 +0100 Received: from dslb-088-078-026-213.088.078.pools.vodafone-ip.de ([88.78.26.213] helo=localhost) by mailfront11.runbox.com with esmtpsa (uid:892961 ) (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1ejlMO-0007Ll-5y for guix-devel@gnu.org; Thu, 08 Feb 2018 13:31:28 +0100 In-Reply-To: (=?utf-8?Q?=22G=C3=A1bor?= Boskovits"'s message of "Thu, 8 Feb 2018 13:09:30 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Guix-devel On Thu, 08 Feb 2018, Gábor Boskovits wrote: > 2018-02-08 12:25 GMT+01:00 : > >> On Tue, 06 Feb 2018, ng0@n0.is wrote: >> > On second thoughts I think it's okay to have all of this in >> > public, there are no stupid questions. >> > >> > On Mon, 05 Feb 2018, ludo@gnu.org (Ludovic Courtès) wrote: >> >> Heya, >> >> >> >> ng0@n0.is skribis: >> >> >> >>> Sorry for the offlist message, but I thought since you list >> >>> yourself as possible mentor for the item I'd ask. >> >> >> >> What? I didn’t add myself there I think, we should find out where that >> >> comes from. :-) >> > >> > So.. who added Ludovic to the RISC-V item? And if not Ludovic, >> > who'd be a good mentor for this item (and has time to spend on >> > it)? Manolis has worked on porting to a different kernel, Efraim >> > has worked on porting to another architecture. >> > >> >>> With regards to RISC-V porting: a question I don't dare asking in >> >>> public because it's answer could be too obvious: is the porting >> >>> possible without owning any real RISC-V hardware? >> >> >> >> I know very little about RISC-V, but I suppose QEMU could help (and most >> >> of the porting work is about getting cross-compilation right.) >> >> >> >>> I think at this point I know enough in Guix to port it to another >> >>> architecture and would apply for this when the GSoC student >> >>> applications are open, depending on your reply. >> >> >> >> Cool. I think you’re welcome to discuss publicly the details and, as a >> >> last resort, privately with the person who submitted this idea (I don’t >> >> remember who that was, but we could ask on the list.) >> >> >> >> Cheers, >> >> Ludo’. >> >> >> > >> > So, ahead of time, I'm interested in porting Guix to >> > RISC-V. Looking at the timeline on the Google GSoC website it >> > falls into my next semester where I can't tell you right how many >> > hours I have available. >> > Students applications period starts in March, so that gives me >> > enough time to look into how porting without owning the hardware >> > works, refreshing my memory on it (recently I've read about slow >> > but native compiling of ARM on qemu). >> > As Ludovic wrote, and by my understanding of porting, it will >> > mostly cover bootstrap + ideally having a compiled (better: >> > functional) Guix on RISC-V? >> >> I've started looking into the details of how Fedora and Debian >> did it. Would be really good if we'd get glibc-2.27 in the next >> couple of months because 2.27 added RISC-V support. That's not a >> precondition for porting but it would help later on. >> I guess we have 2.27 in core-updates? >> >> > Unfortunately, no. We actually have 2.26 currently. > As we are trying to get core-updates merged soon, I guess it will > only into the next core-updates cycle. However we do have everything else, > the binutils and gcc support is already on core-updates. > > I guess that we could give it a try without actual hardware. Yup, exactly what Fedora + Debian do (qemu etc). > We should not > support the architecture officially until we have build farm > capacity. Right, I agree. > I currently see porting to RISC-V a bootstrapping issue, it would be really > nice if we could relax assumptions about hardware. > > I am really interested in this, and I proposed the idea, but: > 1. the toolchain is not really reliable yet, according to conversations on > the > #bootstrappable channel. Yeah, I've noticed that too. On the other hand RISC-V mailinglists speak of starting first application ports (Java for example). I guess more reading, in about a week I have time to do this, will give me a better view on the problems and situation of RISC-V in the real world + our own toolchain. > 2. Ricardo noted, that this kind of project can be quite discouraging for > new > contributors, as it requires lot of time to build. Well, I'm not a new contributor (I only had to change my email address again, multiple reasons etc. I'll stick to this domain now.).. Time spent building is no problem for me. Plus I need only little help I'd guess, being 3+ years in this project. It's nothing that will require lots of Guile expertise (I wouldn't call myself an Guile expert, but by now I'm starting to grok g-exps, which wasn't the case 2 years ago). > If you are still willing to try this, in spite of the concerns raised > above, then I > guess we could arrange mentoring you. Okay, great. As I wrote above, I'll look into the Debian + Fedora material and will take a good guess about weather we are too early for this on Guix or not. >> I have a couple more exams and tests upcoming, but I'll start >> writing the application soon. I have some vague ideas how this >> could be done and need to read into Fedora's approach more to >> write up something that fits for us. >> I guess this is how it usually goes, write an application, >> discuss the application and then decide wether this would work >> out for the GSoC item and submit to Google.. According to what I >> saw here in the past and read this year at the Google Summer of >> Code website at Google. >> -- >> ng0 :: https://crash.cx >> A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://crash.cx/keys/ >> >> -- ng0 :: https://crash.cx A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://crash.cx/keys/