Re: GSoC

[ng0@crash.cx]

On Thu, 08 Feb 2018, Gábor Boskovits <boskovits@gmail.com> wrote:
> 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è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/