From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor_Boskovits?= Subject: Re: GSoC Date: Thu, 8 Feb 2018 13:09:30 +0100 Message-ID: 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: multipart/alternative; boundary="001a114403d0c300e50564b248c8" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59625) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ejl1G-00061O-Id for guix-devel@gnu.org; Thu, 08 Feb 2018 07:09:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ejl1A-0007F1-Ru for guix-devel@gnu.org; Thu, 08 Feb 2018 07:09:38 -0500 Received: from mail-it0-x22d.google.com ([2607:f8b0:4001:c0b::22d]:36139) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ejl1A-0007EG-ES for guix-devel@gnu.org; Thu, 08 Feb 2018 07:09:32 -0500 Received: by mail-it0-x22d.google.com with SMTP id n206so6134196itg.1 for ; Thu, 08 Feb 2018 04:09:32 -0800 (PST) In-Reply-To: <87r2pv67vv.fsf@abyayala.i-did-not-set--mail-host-address--so-tickle-me> 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: ng0@crash.cx Cc: Guix-devel --001a114403d0c300e50564b248c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=C3=A8s) 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=E2=80=99t add myself there I think, we should find out w= here 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 mo= st > >> 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=E2=80=99re welcome to discuss publicly the details = and, as a > >> last resort, privately with the person who submitted this idea (I don= =E2=80=99t > >> remember who that was, but we could ask on the list.) > >> > >> Cheers, > >> Ludo=E2=80=99. > >> > > > > 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. We should not support the architecture officially until we have build farm capacity. 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. 2. Ricardo noted, that this kind of project can be quite discouraging for new contributors, as it requires lot of time to build. If you are still willing to try this, in spite of the concerns raised above, then I guess we could arrange mentoring you. > 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/ > > --001a114403d0c300e50564b248c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
2018= -02-08 12:25 GMT+01:00 <ng0@crash.cx>:
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=C3=A8s) 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?=C2=A0 I didn=E2=80=99t add myself there I think, we should f= ind out where that
>> comes from.=C2=A0 :-)
>
> 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 as= king in
>>> public because it's answer could be too obvious: is the po= rting
>>> possible without owning any real RISC-V hardware?
>>
>> I know very little about RISC-V, but I suppose QEMU could help (an= d 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 anot= her
>>> architecture and would apply for this when the GSoC student >>> applications are open, depending on your reply.
>>
>> Cool.=C2=A0 I think you=E2=80=99re welcome to discuss publicly the= details and, as a
>> last resort, privately with the person who submitted this idea (I = don=E2=80=99t
>> remember who that was, but we could ask on the list.)
>>
>> Cheers,
>> Ludo=E2=80=99.
>>
>
> 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<= br> > 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 Deb= ian
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.=C2=A0

I guess that we could give = it a try without actual hardware. We should not
support the archi= tecture officially until we have build farm capacity.
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 th= e
#bootstrappable channel.
2. Ricardo noted, that this = kind of project can be quite discouraging for new
contributors, a= s it requires lot of time to build.

If you are sti= ll willing to try this, in spite of the concerns raised above, then I
=
guess we could arrange mentoring you.
=C2=A0
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 :: ht= tps://crash.cx
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://crash.cx/keys/

--001a114403d0c300e50564b248c8--