Re: GSoC

[ng0]

On Thu, 08 Feb 2018, address@hidden wrote:
> On Thu, 08 Feb 2018, Gábor Boskovits <address@hidden> wrote:
>> 2018-02-08 12:25 GMT+01:00 <address@hidden>:
>>
>>> On Tue, 06 Feb 2018, address@hidden 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, address@hidden (Ludovic Courtès) wrote:
>>> >> Heya,
>>> >>
>>> >> address@hidden 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).

Addition: I don't know what to expect, I know what mentoring is,
I just wanted to express that I feel like I understand a good
part of Guix, a bit about the way it bootstraps, and I'm patient
when it comes to doing lots of building for a long time. I just
felt I didn't express this in the quoted message. I will probably
still have questions should we find this item doable at this
stage of RISC-V toolchain support.

>> 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/