2018-02-08 12:25 GMT+01:00 <n...@crash.cx>:

> On Tue, 06 Feb 2018, n...@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, l...@gnu.org (Ludovic Courtès) wrote:
> >> Heya,
> >>
> >> n...@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. 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
#bootstrappable channel.
2. Ricardo noted, that this kind of project can be quite discouraging for
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/

Reply via email to