12:03 p.m.
Hi all! I just got back from Open Source Summit, several of the talks I
found interesting were on RISC-V -- a high-level one about the
organizational structure, and Drew Fustini's more technical talk.
In that, he noted that there's a Fedora build *, but it isn't an official
Fedora arch. As I understand it, the major infrastructure blocker is simply
that there isn't server-class hardware (let alone hardware that will build
fast enough that it isn't a frustrating bottleneck).
So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances
as builders, could we build fast enough under QEMU emulation to work? We
have a nice early advantage, but if we don't keep moving, we'll lose that.
But beyond that: What other things might be limits? Are there key bits of
the distro which don't build yet? Is there a big enough risc-v team to
respond to arch-specific build failures? And, do we have enough people to do
QA around release time?
* see http://fedora.riscv.rocks/koji/
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
12:23 p.m.
I've been wanting to work with RISC-V for a while, but it's been really
difficult to get my hands on a dev board. I spoke with Mark Himmelstein
from RISC-V International last week and he mentioned that they are pushing
hard to get more dev boards out... but they're getting hit with the chip
shortage just like everyone else.
I really look forward to the day when Open ISAs like RISC-V and OpenPower
have better availability. I know I'm eager to move to them as soon as I
can.
I have no experience with emulating it, so I can't really give any feedback
on that. Do we have a RISC-V SIG?
JT
On Mon, Oct 4, 2021 at 1:03 PM Matthew Miller <mattdm(a)fedoraproject.org>
wrote:
Hi all! I just got back from Open Source Summit, several of the talks
I
found interesting were on RISC-V -- a high-level one about the
organizational structure, and Drew Fustini's more technical talk.
In that, he noted that there's a Fedora build *, but it isn't an official
Fedora arch. As I understand it, the major infrastructure blocker is simply
that there isn't server-class hardware (let alone hardware that will build
fast enough that it isn't a frustrating bottleneck).
So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances
as builders, could we build fast enough under QEMU emulation to work? We
have a nice early advantage, but if we don't keep moving, we'll lose that.
But beyond that: What other things might be limits? Are there key bits of
the distro which don't build yet? Is there a big enough risc-v team to
respond to arch-specific build failures? And, do we have enough people to
do
QA around release time?
* see http://fedora.riscv.rocks/koji/
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
12:35 p.m.
On Mon, Oct 4, 2021 at 7:04 PM Matthew Miller <mattdm(a)fedoraproject.org> wrote:
Hi all! I just got back from Open Source Summit, several of the talks I
found interesting were on RISC-V -- a high-level one about the
organizational structure, and Drew Fustini's more technical talk.
In that, he noted that there's a Fedora build *, but it isn't an official
Fedora arch. As I understand it, the major infrastructure blocker is simply
that there isn't server-class hardware (let alone hardware that will build
fast enough that it isn't a frustrating bottleneck).
So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances
as builders, could we build fast enough under QEMU emulation to work? We
have a nice early advantage, but if we don't keep moving, we'll lose that.
But beyond that: What other things might be limits? Are there key bits of
the distro which don't build yet? Is there a big enough risc-v team to
respond to arch-specific build failures? And, do we have enough people to do
QA around release time?
I think the primary problem here is that koji does support neither
external builders nor building on top of qemu emulation.
However, COPR *does* support building on emulated architectures
(that's how its armv7 and s390x support works there).
So, maybe adding a mock configuration for building RISC-V packages in
qemu emulation, with the fedora repositories from
http://fedora.riscv.rocks/koji/ as a base, could work until koji
supports it?
(I think that would involve either adding RISC-V hardware to Fedora
Infrastructure, or adding support for emulated architectures to koji,
or adding support for external builders to koji.)
Fabio
1:23 p.m.
On Mon, Oct 4, 2021 at 1:35 PM Fabio Valentini <decathorpe(a)gmail.com> wrote:
On Mon, Oct 4, 2021 at 7:04 PM Matthew Miller <mattdm(a)fedoraproject.org> wrote:
>
> Hi all! I just got back from Open Source Summit, several of the talks I
> found interesting were on RISC-V -- a high-level one about the
> organizational structure, and Drew Fustini's more technical talk.
>
> In that, he noted that there's a Fedora build *, but it isn't an official
> Fedora arch. As I understand it, the major infrastructure blocker is simply
> that there isn't server-class hardware (let alone hardware that will build
> fast enough that it isn't a frustrating bottleneck).
>
> So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances
> as builders, could we build fast enough under QEMU emulation to work? We
> have a nice early advantage, but if we don't keep moving, we'll lose that.
>
> But beyond that: What other things might be limits? Are there key bits of
> the distro which don't build yet? Is there a big enough risc-v team to
> respond to arch-specific build failures? And, do we have enough people to do
> QA around release time?
I think the primary problem here is that koji does support neither
external builders nor building on top of qemu emulation.
However, COPR *does* support building on emulated architectures
(that's how its armv7 and s390x support works there).
So, maybe adding a mock configuration for building RISC-V packages in
qemu emulation, with the fedora repositories from
http://fedora.riscv.rocks/koji/ as a base, could work until koji
supports it?
(I think that would involve either adding RISC-V hardware to Fedora
Infrastructure, or adding support for emulated architectures to koji,
or adding support for external builders to koji.)
Perhaps kojivmd could be extended to support foreign architecture VMs?
I think libvirt already can set up VMs with foreign architecture
emulation, and kojivmd already calls libvirt for creating builder VMs.
--
真実はいつも一つ！/ Always, there's only one truth!
1:58 p.m.
I have nothing to add to this conversation other than:
1) I'd love to see RISC-V become a serious contender to X86-64. I'm tired
of being controlled by the Intel/AMD oligopoly.
2) I love seeing Fedora people discuss supporting RISC-V.
3) Linux rocks. Fedora rocks.
4:06 a.m.
On Mon, Oct 4, 2021 at 7:04 PM Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
I think the primary problem here is that koji does support neither
external builders nor building on top of qemu emulation.
However, COPR *does* support building on emulated architectures
(that's how its armv7 and s390x support works there).
I think your wrong about koji not supporting external builders, rpmfusion koji
uses external builders.
2:07 p.m.
On Mon, Oct 04, 2021 at 01:03:27PM -0400, Matthew Miller wrote:
Hi all! I just got back from Open Source Summit, several of the talks
I
found interesting were on RISC-V -- a high-level one about the
organizational structure, and Drew Fustini's more technical talk.
In that, he noted that there's a Fedora build *, but it isn't an official
Fedora arch. As I understand it, the major infrastructure blocker is simply
that there isn't server-class hardware (let alone hardware that will build
fast enough that it isn't a frustrating bottleneck).
We have avoided using emulation in the past because we would be chasing
bugs in our emulation that aren't in real hardware and vice versa.
How good is the emulation support? Do we know/have people who can fix
things in it when we hit them? Tools folks: is emulation an option here?
Or do we still forbid it?
So, one question is: if we used, say, ARM or x86_64 Amazon cloud
instances
as builders, could we build fast enough under QEMU emulation to work? We
have a nice early advantage, but if we don't keep moving, we'll lose that.
But beyond that: What other things might be limits? Are there key bits of
the distro which don't build yet? Is there a big enough risc-v team to
respond to arch-specific build failures? And, do we have enough people to do
QA around release time?
Well, one big thing is that it's been a while since we had any secondary
arches and it's unclear how they would work today. In the distant past
secondary arches had their own koji and builders and composes and
releases and used koji-shadow to try and match up with primary koji.
This was basically more than a full time job for someone and I am sure
koji-shadow has atrophied in recent years, but perhaps at least some
subset could be made to work again.
On the other hand we could just add it into primary koji, but then it
really really has to keep up or it's going to block everything else.
So, probibly a 'secondary' koji and builders to start with to bootstrap
and to gather info on how hard it is to keep up and good emulation is
would be worthwhile, but it's gonna need some dedicated work.
Perhaps we could get a up to date status report from folks working on
this, answering such questions as:
* How good is emulation support
* What would it take to keep up with the other arches? Is that possible?
* What device(s) would we want to target and could we get sufficent
numbers of them for QA and devel folks to debug problems and test?
* Are there folks who can bootstrap/shepard the koji shadowing process?
I think RISC-V is pretty exciting, and I am happy to help as much as I
can with adding it in. I think there's likely to be a lot of
interest/growth in coming years for it.
kevin
2:12 p.m.
On Mon, Oct 4, 2021 at 3:07 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
On Mon, Oct 04, 2021 at 01:03:27PM -0400, Matthew Miller wrote:
> Hi all! I just got back from Open Source Summit, several of the talks I
> found interesting were on RISC-V -- a high-level one about the
> organizational structure, and Drew Fustini's more technical talk.
>
> In that, he noted that there's a Fedora build *, but it isn't an official
> Fedora arch. As I understand it, the major infrastructure blocker is simply
> that there isn't server-class hardware (let alone hardware that will build
> fast enough that it isn't a frustrating bottleneck).
We have avoided using emulation in the past because we would be chasing
bugs in our emulation that aren't in real hardware and vice versa.
How good is the emulation support? Do we know/have people who can fix
things in it when we hit them? Tools folks: is emulation an option here?
Or do we still forbid it?
> So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances
> as builders, could we build fast enough under QEMU emulation to work? We
> have a nice early advantage, but if we don't keep moving, we'll lose that.
>
> But beyond that: What other things might be limits? Are there key bits of
> the distro which don't build yet? Is there a big enough risc-v team to
> respond to arch-specific build failures? And, do we have enough people to do
> QA around release time?
Well, one big thing is that it's been a while since we had any secondary
arches and it's unclear how they would work today. In the distant past
secondary arches had their own koji and builders and composes and
releases and used koji-shadow to try and match up with primary koji.
This was basically more than a full time job for someone and I am sure
koji-shadow has atrophied in recent years, but perhaps at least some
subset could be made to work again.
On the other hand we could just add it into primary koji, but then it
really really has to keep up or it's going to block everything else.
So, probibly a 'secondary' koji and builders to start with to bootstrap
and to gather info on how hard it is to keep up and good emulation is
would be worthwhile, but it's gonna need some dedicated work.
Perhaps we could get a up to date status report from folks working on
this, answering such questions as:
* How good is emulation support
The lack of real hardware for RISC-V has made it so almost everyone is
working with emulation. It's not realistic right now to work with real
hardware.
* What would it take to keep up with the other arches? Is that
possible?
The real hardware options do not have the performance to keep up with
the other architectures.
* What device(s) would we want to target and could we get sufficent
numbers of them for QA and devel folks to debug problems and test?
This is probably more of a question for Fedora RISC-V folks like
Richard W.M. Jones...
* Are there folks who can bootstrap/shepard the koji shadowing
process?
We already have the other Koji instance that could be converted into a
shadow Koji, couldn't it?
--
真実はいつも一つ！/ Always, there's only one truth!
10:35 a.m.
On Mon, Oct 4, 2021 at 10:13 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Mon, Oct 4, 2021 at 3:07 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
>
> On Mon, Oct 04, 2021 at 01:03:27PM -0400, Matthew Miller wrote:
> > Hi all! I just got back from Open Source Summit, several of the talks I
> > found interesting were on RISC-V -- a high-level one about the
> > organizational structure, and Drew Fustini's more technical talk.
> >
> > In that, he noted that there's a Fedora build *, but it isn't an
official
> > Fedora arch. As I understand it, the major infrastructure blocker is simply
> > that there isn't server-class hardware (let alone hardware that will build
> > fast enough that it isn't a frustrating bottleneck).
>
> We have avoided using emulation in the past because we would be chasing
> bugs in our emulation that aren't in real hardware and vice versa.
> How good is the emulation support? Do we know/have people who can fix
> things in it when we hit them? Tools folks: is emulation an option here?
> Or do we still forbid it?
>
> > So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances
> > as builders, could we build fast enough under QEMU emulation to work? We
> > have a nice early advantage, but if we don't keep moving, we'll lose
that.
> >
> > But beyond that: What other things might be limits? Are there key bits of
> > the distro which don't build yet? Is there a big enough risc-v team to
> > respond to arch-specific build failures? And, do we have enough people to do
> > QA around release time?
>
> Well, one big thing is that it's been a while since we had any secondary
> arches and it's unclear how they would work today. In the distant past
> secondary arches had their own koji and builders and composes and
> releases and used koji-shadow to try and match up with primary koji.
> This was basically more than a full time job for someone and I am sure
> koji-shadow has atrophied in recent years, but perhaps at least some
> subset could be made to work again.
>
> On the other hand we could just add it into primary koji, but then it
> really really has to keep up or it's going to block everything else.
>
> So, probibly a 'secondary' koji and builders to start with to bootstrap
> and to gather info on how hard it is to keep up and good emulation is
> would be worthwhile, but it's gonna need some dedicated work.
>
> Perhaps we could get a up to date status report from folks working on
> this, answering such questions as:
>
> * How good is emulation support
The lack of real hardware for RISC-V has made it so almost everyone is
working with emulation. It's not realistic right now to work with real
hardware.
> * What would it take to keep up with the other arches? Is that possible?
Right now we run 170 QEMUs and a few boards. Most QEMU VMs run with 4
cores, but some are configured with 8 cores + 32GB of RAM.
The number of boards (physical machines) will increase.
With the QEMU setup we could deliver thousands of builds per week.
Of course we cannot fully keep up. For example OpenJDK doesn't have a
JIT which can be used in some packages (building or running tests).
In general we have been running Fedora GNOME Wayland Desktop setup
with RISC-V SoC (SiFive) + AMD GPUs for years now. I can even play a
4K movie (thanks to the GPU acceleration).
The real hardware options do not have the performance to keep up with
the other architectures.
> * What device(s) would we want to target and could we get sufficent
> numbers of them for QA and devel folks to debug problems and test?
This is probably more of a question for Fedora RISC-V folks like
Richard W.M. Jones...
The only device capable of PC-like setup is SiFive Unmatched today.
That's the only board you could buy.
There are cheaper boards based on Allwinner D1, but that cheap is a
complicated story. They used some reversed bits in PTE and RVV is
0.7.1, which is not compatible with what will be ratified. Technically
the chip can run in "compatible" mode, but that would kill peripherals
IIUC.
The current RISC-V Platforms and Profiles specifications are also not
finished thus there aren't any devices that would have the official
stamps of some compatibility level. If everything goes well these
things will be finalized / ratified sooner than later.
> * Are there folks who can bootstrap/shepard the koji shadowing process?
>
We already have the other Koji instance that could be converted into a
shadow Koji, couldn't it?
I currently avoided "koji shadow" and used my silly scripts (which
works as long as you learn all Fedora packages and how things work
with some packages/ecosystems).
Cheers,
david
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
12:50 p.m.
On 10/4/21 12:12 PM, Neal Gompa wrote:
On Mon, Oct 4, 2021 at 3:07 PM Kevin Fenzi <kevin(a)scrye.com>
wrote:
> * How good is emulation support
The lack of real hardware for RISC-V has made it so almost everyone is
working with emulation. It's not realistic right now to work with real
hardware.
> * What would it take to keep up with the other arches? Is that possible?
The real hardware options do not have the performance to keep up with
the other architectures.
Is it really so slow that emulation is preferable?
2:17 p.m.
On Wed, Oct 06, 2021 at 10:50:02AM -0700, Josh Stone wrote:
> The real hardware options do not have the performance to keep up
with
> the other architectures.
Is it really so slow that emulation is preferable?
Speed isn't the only concern -- in order to be reasonably manageable, we
need this to be server-class hardware. Or at the very least, rackmount
hardware. Dev boards -- even fast ones -- don't help much.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
5:17 p.m.
On Wed, Oct 06, 2021 at 10:50:02AM -0700, Josh Stone wrote:
On 10/4/21 12:12 PM, Neal Gompa wrote:
> On Mon, Oct 4, 2021 at 3:07 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
>> * How good is emulation support
>
> The lack of real hardware for RISC-V has made it so almost everyone is
> working with emulation. It's not realistic right now to work with real
> hardware.
>
>> * What would it take to keep up with the other arches? Is that possible?
>
> The real hardware options do not have the performance to keep up with
> the other architectures.
Is it really so slow that emulation is preferable?
Actually we prefer the real hardware over qemu for the larger builds.
As the other reply said the main concern is the lack of server-class
hardware. We could build something with a Pi KVM hat, but that's not
a neat integrated solution.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
5:29 p.m.
On Wed, Oct 6, 2021 at 1:50 PM Josh Stone <jistone(a)redhat.com> wrote:
On 10/4/21 12:12 PM, Neal Gompa wrote:
> On Mon, Oct 4, 2021 at 3:07 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
>> * How good is emulation support
>
> The lack of real hardware for RISC-V has made it so almost everyone is
> working with emulation. It's not realistic right now to work with real
> hardware.
>
>> * What would it take to keep up with the other arches? Is that possible?
>
> The real hardware options do not have the performance to keep up with
> the other architectures.
Is it really so slow that emulation is preferable?
In my opinion, yes. There's a dearth of so-called "server-class"
hardware, which have such useful characteristics like "large amounts
of RAM", "decent memory cache", "fast I/O", "PCIe
lanes", and so on.
The development boards typically are very I/O constrained and have
limited amounts of RAM, making them less useful than emulation for
doing builds.
--
真実はいつも一つ！/ Always, there's only one truth!
1:03 p.m.
On Thu, Oct 7, 2021 at 1:30 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Wed, Oct 6, 2021 at 1:50 PM Josh Stone <jistone(a)redhat.com> wrote:
>
> On 10/4/21 12:12 PM, Neal Gompa wrote:
> > On Mon, Oct 4, 2021 at 3:07 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
> >> * How good is emulation support
> >
> > The lack of real hardware for RISC-V has made it so almost everyone is
> > working with emulation. It's not realistic right now to work with real
> > hardware.
> >
> >> * What would it take to keep up with the other arches? Is that possible?
> >
> > The real hardware options do not have the performance to keep up with
> > the other architectures.
>
> Is it really so slow that emulation is preferable?
>
In my opinion, yes. There's a dearth of so-called "server-class"
hardware, which have such useful characteristics like "large amounts
of RAM", "decent memory cache", "fast I/O", "PCIe
lanes", and so on.
The development boards typically are very I/O constrained and have
limited amounts of RAM, making them less useful than emulation for
doing builds.
We tried to improve the situation with SiFive Unmatched:
- 16GiB of RAM (twice more compared to SiFive Unleashed);
- PCIe Gen 3;
- M.2 NVMe (via PCIe switch);
- M.2 for WiFi/BT card (via PCIe switch);
- USB-As (via PCIe switch);
- You can boot firmware (OpenSBI/DT/U-Boot) via microSD card instead
of SPI-NOR Flash. With SD-Muxer you could update all those bits for
testing;
- mini-ITX (you can put those boards in the rackmount cases);
- ATX power supply;
- Front panel header connector;
- Multiple fan headers;
- and more.
It's not perfect, but it's a decent upgrade for the 2nd generation
SiFive board and the setup is way cheaper too.
Pi KVM could provide some remote management (didn't try, might get one
in the future to test).
Cheers,
david
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
3:39 p.m.
On Mon, Oct 04, 2021 at 12:07:30PM -0700, Kevin Fenzi wrote:
On Mon, Oct 04, 2021 at 01:03:27PM -0400, Matthew Miller wrote:
> Hi all! I just got back from Open Source Summit, several of the talks I
> found interesting were on RISC-V -- a high-level one about the
> organizational structure, and Drew Fustini's more technical talk.
>
> In that, he noted that there's a Fedora build *, but it isn't an official
> Fedora arch. As I understand it, the major infrastructure blocker is simply
> that there isn't server-class hardware (let alone hardware that will build
> fast enough that it isn't a frustrating bottleneck).
We have avoided using emulation in the past because we would be chasing
bugs in our emulation that aren't in real hardware and vice versa.
How good is the emulation support? Do we know/have people who can fix
things in it when we hit them? Tools folks: is emulation an option here?
Or do we still forbid it?
Qemu support for RISC-V is very good, it's actually used to develop
some features (virtualization and SBI). We do know people who can fix it.
If you have the money real hardware is also available now.
Personally speaking I think the real barrier is someone with a large
colourful hat putting up the money to hire a full time developer to
work on the project.
Rich.
> So, one question is: if we used, say, ARM or x86_64 Amazon cloud
instances
> as builders, could we build fast enough under QEMU emulation to work? We
> have a nice early advantage, but if we don't keep moving, we'll lose that.
>
> But beyond that: What other things might be limits? Are there key bits of
> the distro which don't build yet? Is there a big enough risc-v team to
> respond to arch-specific build failures? And, do we have enough people to do
> QA around release time?
Well, one big thing is that it's been a while since we had any secondary
arches and it's unclear how they would work today. In the distant past
secondary arches had their own koji and builders and composes and
releases and used koji-shadow to try and match up with primary koji.
This was basically more than a full time job for someone and I am sure
koji-shadow has atrophied in recent years, but perhaps at least some
subset could be made to work again.
On the other hand we could just add it into primary koji, but then it
really really has to keep up or it's going to block everything else.
So, probibly a 'secondary' koji and builders to start with to bootstrap
and to gather info on how hard it is to keep up and good emulation is
would be worthwhile, but it's gonna need some dedicated work.
Perhaps we could get a up to date status report from folks working on
this, answering such questions as:
* How good is emulation support
* What would it take to keep up with the other arches? Is that possible?
* What device(s) would we want to target and could we get sufficent
numbers of them for QA and devel folks to debug problems and test?
* Are there folks who can bootstrap/shepard the koji shadowing process?
I think RISC-V is pretty exciting, and I am happy to help as much as I
can with adding it in. I think there's likely to be a lot of
interest/growth in coming years for it.
kevin
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
3:47 p.m.
On Monday, 04 October 2021 at 22:39, Richard W.M. Jones wrote:
[...]
Personally speaking I think the real barrier is someone with a large
colourful hat putting up the money to hire a full time developer to
work on the project.
Also, I think one of the pre-requisites to enabling it in koji would be
making at least one machine available to package maintainers.
Regards,
Dominik
--
Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
12:44 a.m.
https://www.opensourcevoices.org/20
On Mon, Oct 4, 2021 at 10:47 PM Dominik 'Rathann' Mierzejewski <
dominik(a)greysector.net> wrote:
On Monday, 04 October 2021 at 22:39, Richard W.M. Jones wrote:
[...]
> Personally speaking I think the real barrier is someone with a large
> colourful hat putting up the money to hire a full time developer to
> work on the project.
Also, I think one of the pre-requisites to enabling it in koji would be
making at least one machine available to package maintainers.
Regards,
Dominik
--
Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
5:11 a.m.
On Mon, Oct 04, 2021 at 10:47:14PM +0200, Dominik 'Rathann' Mierzejewski wrote:
On Monday, 04 October 2021 at 22:39, Richard W.M. Jones wrote:
[...]
> Personally speaking I think the real barrier is someone with a large
> colourful hat putting up the money to hire a full time developer to
> work on the project.
Also, I think one of the pre-requisites to enabling it in koji would be
making at least one machine available to package maintainers.
I agree. In practice it would likely be easier to ensure that we have
clearer instructions for setting up qemu and timely delivery of images
to run on qemu, eg through virt-builder. (I don't know about anyone
else but I much prefer to work on something in a local environment.)
This would be something for the person hired above to do.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
10:24 a.m.
On Mon, Oct 04, 2021 at 10:47:14PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> Personally speaking I think the real barrier is someone with a
large
> colourful hat putting up the money to hire a full time developer to
> work on the project.
Also, I think one of the pre-requisites to enabling it in koji would be
making at least one machine available to package maintainers.
Yeah, I think we'd want to have at least a remote-shell system plus also an
initiative to get dev boards to maintainers with specific interest.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
8:55 a.m.
On 10/5/21 04:39, Richard W.M. Jones wrote:
On Mon, Oct 04, 2021 at 12:07:30PM -0700, Kevin Fenzi wrote:
> On Mon, Oct 04, 2021 at 01:03:27PM -0400, Matthew Miller wrote:
>> Hi all! I just got back from Open Source Summit, several of the talks I
>> found interesting were on RISC-V -- a high-level one about the
>> organizational structure, and Drew Fustini's more technical talk.
>>
>> In that, he noted that there's a Fedora build *, but it isn't an
official
>> Fedora arch. As I understand it, the major infrastructure blocker is simply
>> that there isn't server-class hardware (let alone hardware that will build
>> fast enough that it isn't a frustrating bottleneck).
>
> We have avoided using emulation in the past because we would be chasing
> bugs in our emulation that aren't in real hardware and vice versa.
> How good is the emulation support? Do we know/have people who can fix
> things in it when we hit them? Tools folks: is emulation an option here?
> Or do we still forbid it?
Qemu support for RISC-V is very good, it's actually used to develop
some features (virtualization and SBI). We do know people who can fix it.
If you have the money real hardware is also available now.
Personally speaking I think the real barrier is someone with a large
colourful hat putting up the money to hire a full time developer to
work on the project.
I know Wei FU(FAS: tekkamanninja) is actively working on porting Fedora
to RISC-V. He has his BSP for D1 which he already put up a wiki[1]. I'm
about to help him get LXQt desktop up on D1 soon.
In current situation maybe it makes more sense to start thinking about
making all RISC-V contributors work together rather than doing
everything on each own, which would be much efficient.
[1] https://fedoraproject.org/wiki/Architectures/RISC-V/Allwinner
Rich.
>> So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances
>> as builders, could we build fast enough under QEMU emulation to work? We
>> have a nice early advantage, but if we don't keep moving, we'll lose
that.
>>
>> But beyond that: What other things might be limits? Are there key bits of
>> the distro which don't build yet? Is there a big enough risc-v team to
>> respond to arch-specific build failures? And, do we have enough people to do
>> QA around release time?
>
> Well, one big thing is that it's been a while since we had any secondary
> arches and it's unclear how they would work today. In the distant past
> secondary arches had their own koji and builders and composes and
> releases and used koji-shadow to try and match up with primary koji.
> This was basically more than a full time job for someone and I am sure
> koji-shadow has atrophied in recent years, but perhaps at least some
> subset could be made to work again.
>
> On the other hand we could just add it into primary koji, but then it
> really really has to keep up or it's going to block everything else.
>
> So, probibly a 'secondary' koji and builders to start with to bootstrap
> and to gather info on how hard it is to keep up and good emulation is
> would be worthwhile, but it's gonna need some dedicated work.
>
> Perhaps we could get a up to date status report from folks working on
> this, answering such questions as:
>
> * How good is emulation support
> * What would it take to keep up with the other arches? Is that possible?
> * What device(s) would we want to target and could we get sufficent
> numbers of them for QA and devel folks to debug problems and test?
> * Are there folks who can bootstrap/shepard the koji shadowing process?
>
> I think RISC-V is pretty exciting, and I am happy to help as much as I
> can with adding it in. I think there's likely to be a lot of
> interest/growth in coming years for it.
>
> kevin
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
Zamir SUN
GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E
Want to know more about Fedora?
Visit https://fedoraproject.org/wiki/
Ready to contribute? See https://whatcanidoforfedora.org/
想了解更多中文资讯，访问 https://zh.fedoracommunity.org/
2:04 p.m.
On 04 Oct 2021 21:39, Richard W.M. Jones wrote:
Personally speaking I think the real barrier is someone with a large
colourful hat putting up the money to hire a full time developer to
work on the project.
Rich.
Big ol' +1 to that.
--
ciao,
al
-----------------------------------
Al Stone
Principal Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------
3:36 p.m.
On Mon, Oct 04, 2021 at 01:03:27PM -0400, Matthew Miller wrote:
Hi all! I just got back from Open Source Summit, several of the talks
I
found interesting were on RISC-V -- a high-level one about the
organizational structure, and Drew Fustini's more technical talk.
In that, he noted that there's a Fedora build *, but it isn't an official
Fedora arch. As I understand it, the major infrastructure blocker is simply
that there isn't server-class hardware (let alone hardware that will build
fast enough that it isn't a frustrating bottleneck).
The hardware situation is actually not terrible now (albeit still very
expensive). HiFive Unmatched is a very solid platform that supports
mini ITX, a decent amount of RAM, M.2 SSD, AMD Radeon GPU. You can
build a reasonable desktop-style machine with one of the boards.
For servers there are several missing components:
- Any kind of BMC or remote management. You can add a Raspberry
Pi-based KVM hat (assuming you're happy with that incongruity)
- UEFI, although it's coming and u-boot works OK.
Qemu also works very well if you don't want or more likely can't
afford the hardware.
So, one question is: if we used, say, ARM or x86_64 Amazon cloud
instances
as builders, could we build fast enough under QEMU emulation to work? We
have a nice early advantage, but if we don't keep moving, we'll lose that.
But beyond that: What other things might be limits? Are there key bits of
the distro which don't build yet? Is there a big enough risc-v team to
respond to arch-specific build failures? And, do we have enough people to do
QA around release time?
I think we have most things covered. Hardware doesn't support
virtualization but Qemu does. Hardware doesn't support various
desirable features like the vector extension. Also it'd be nice to
have a JDK port.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
10:17 a.m.
On Mon, Oct 4, 2021 at 12:03 PM Matthew Miller <mattdm(a)fedoraproject.org> wrote:
Hi all! I just got back from Open Source Summit, several of the talks I
found interesting were on RISC-V -- a high-level one about the
organizational structure, and Drew Fustini's more technical talk.
In that, he noted that there's a Fedora build *, but it isn't an official
Fedora arch. As I understand it, the major infrastructure blocker is simply
that there isn't server-class hardware (let alone hardware that will build
fast enough that it isn't a frustrating bottleneck).
So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances
as builders, could we build fast enough under QEMU emulation to work? We
have a nice early advantage, but if we don't keep moving, we'll lose that.
But beyond that: What other things might be limits? Are there key bits of
the distro which don't build yet? Is there a big enough risc-v team to
respond to arch-specific build failures? And, do we have enough people to do
QA around release time?
Kernel is still an issue, in that the changes to support RISC-V have
not been merged yet, though I expect that is not a massive
undertaking.
Justin
2:08 p.m.
On 06 Oct 2021 10:17, Justin Forbes wrote:
On Mon, Oct 4, 2021 at 12:03 PM Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
>
> Hi all! I just got back from Open Source Summit, several of the talks I
> found interesting were on RISC-V -- a high-level one about the
> organizational structure, and Drew Fustini's more technical talk.
>
> In that, he noted that there's a Fedora build *, but it isn't an official
> Fedora arch. As I understand it, the major infrastructure blocker is simply
> that there isn't server-class hardware (let alone hardware that will build
> fast enough that it isn't a frustrating bottleneck).
>
> So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances
> as builders, could we build fast enough under QEMU emulation to work? We
> have a nice early advantage, but if we don't keep moving, we'll lose that.
>
> But beyond that: What other things might be limits? Are there key bits of
> the distro which don't build yet? Is there a big enough risc-v team to
> respond to arch-specific build failures? And, do we have enough people to do
> QA around release time?
Kernel is still an issue, in that the changes to support RISC-V have
not been merged yet, though I expect that is not a massive
undertaking.
Justin
Not been merged? Or just not turned on in the config?
--
ciao,
al
-----------------------------------
Al Stone
Principal Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------
5:19 p.m.
I posted the same article on Fedora Discussion.[1] However let me
share it again on the devel@ to tell it to many people.
This is interesting news about RISC-V this week. Perhaps, it’s time to
prepare to add the RISC-V CPU to the Koji build system?
Google wants RISC-V to be a “tier-1” Android architecture
https://arstechnica.com/gadgets/2023/01/google-announces-official-android...
Arm has become an unstable, volatile business partner
[1]
https://discussion.fedoraproject.org/t/risc-v-server-spec-for-fedora-koji...
--
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See <https://www.worldtimebuddy.com/czech-republic-prague-to-utc> for
the timezone.
6:42 p.m.
On 1/6/23 16:19, Jun Aruga (he / him) wrote:
I posted the same article on Fedora Discussion.[1] However let me
share it again on the devel@ to tell it to many people.
This is interesting news about RISC-V this week. Perhaps, it’s time to
prepare to add the RISC-V CPU to the Koji build system?
I think the big question in this space is access to suitable hardware.
What's out there right now is scarce and woefully under-powered.
My plan is to set up and maintain a riscv64 shadow builder as soon as
possible after our Veyron-v1 bring-up. Ideally that will help forge a
path to official Fedora builds as hardware availability expands.
jeff
12:41 a.m.
On Sat, Jan 7, 2023 at 2:42 AM Jeff Law <jeffreyalaw(a)gmail.com> wrote:
On 1/6/23 16:19, Jun Aruga (he / him) wrote:
> I posted the same article on Fedora Discussion.[1] However let me
> share it again on the devel@ to tell it to many people.
>
> This is interesting news about RISC-V this week. Perhaps, it’s time to
> prepare to add the RISC-V CPU to the Koji build system?
>
I think the big question in this space is access to suitable hardware.
What's out there right now is scarce and woefully under-powered.
Summary from multi-year discussions/feedback on this:
- We don't have proper hardware to put into the data center that holds
servers used by Fedora infrastructure.
- Not enough single and multi thread performance to avoid large impact
to Fedora development.
Other than that Fedora/RISCV 37 is the first Fedora version to be
built fully natively using 20+ SiFive HiFive Unmatched boards. On a
good day we can keep up (if the builds aren't too large, e.g. GCC). We
don't really run Bodhi thus once package is built it's immediately
available. We run a very minimal setup right now (ideas to expand
that).
Another news is that Fedora/RISCV Koji server (
http://fedora.riscv.rocks/koji/ ) just moved into Fedora infra owned
server. We are about to start work on Fedora 38/Rawhide.
2023 is potentially a transition year. Ventana Veyron V1 Development
Platform looks good (I assume it has BMC). SOPHGO SG2042 should also
show up with 64-core @ 2.0GHz (T-HEAD C910) in early 2023 (?) I am not
yet convinced about their upstream support efforts (TBD).
If that's not available with proper support or/and in proper
quantities the plan would be to continue expanding Fedora/RISCV
builders with JH7110 (upstreaming ongoing for kernel/OpenSBI/U-Boot).
Mainly PINE64 Star64 and VisionFive V2 boards. SiFive/Intel Pro P550
(Horse Creek) and that also has OCP DC-SCM for BMC card. Sipeed TH1520
based cluster board (7 modules, BMC incl, T-HEAD C910, up to 16G of
RAM or 4G/core).
My plan is to set up and maintain a riscv64 shadow builder as soon as
possible after our Veyron-v1 bring-up. Ideally that will help forge a
path to official Fedora builds as hardware availability expands.
If there is away to acquire Veyron V1 Development Platform I would be
interested to talk, and figure out what that would take. Such hardware
would be a game charger, and I do trust Ventana regarding upstream
support :)
Cheers,
david
>
>
> jeff
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
1:40 a.m.
On Sun, Jan 8, 2023 at 2:28 AM Jeff Law <jlaw(a)ventanamicro.com> wrote:
On 1/6/23 23:41, David Abdurachmanov wrote:
>
> Summary from multi-year discussions/feedback on this:
> - We don't have proper hardware to put into the data center that holds
> servers used by Fedora infrastructure.
Right. dev boards are not the solution here. It's got to be something
that can be racked and with enough performance to matter.
> - Not enough single and multi thread performance to avoid large impact
> to Fedora development.
Agreed. Returning to a situation like we had with armv7 isn't
acceptable IMHO.
>
> Other than that Fedora/RISCV 37 is the first Fedora version to be
> built fully natively using 20+ SiFive HiFive Unmatched boards. On a
> good day we can keep up (if the builds aren't too large, e.g. GCC). We
> don't really run Bodhi thus once package is built it's immediately
> available. We run a very minimal setup right now (ideas to expand
> that).
It's fantastic we've got that far. But clearly it's not viable long term.
Agreed. We have been cooking Fedora/RISCV since 2016, but we really
cannot move forward until the proper hardware (and things around it)
becomes available.
> Another news is that Fedora/RISCV Koji server (
> http://fedora.riscv.rocks/koji/ ) just moved into Fedora infra owned
> server. We are about to start work on Fedora 38/Rawhide.
Excellent. I'll have to update my chroots and containers as the F38
bits start appearing.
I am still tweaking the server configuration, but I should be ready
for mass building soonish.
I might want to wait for GCC 13 to land in Rawhide, which should
happen soon (I think).
>
> 2023 is potentially a transition year. Ventana Veyron V1 Development
> Platform looks good (I assume it has BMC). SOPHGO SG2042 should also
> show up with 64-core @ 2.0GHz (T-HEAD C910) in early 2023 (?) I am not
> yet convinced about their upstream support efforts (TBD).
Yes Veyron-v1 will have a BMC and will be rackable. I have no
significant insight into the T-HEAD efforts other than they do work a
fair amount with VRULL on compiler and related technology.
I noticed that VRULL has been involved with T-HEAD on GCC and
potentially kernel side for a few months now. This makes them much
more optimistic about their SoC/HW support in general.
>
> If there is away to acquire Veyron V1 Development Platform I would be
> interested to talk, and figure out what that would take. Such hardware
> would be a game charger, and I do trust Ventana regarding upstream
> support :)
I'll be pushing to make systems available to Fedora and the GCC farm,
but in general Ventana is more aligned towards Ubuntu. My goal is to
have Fedora and Ubuntu on equal footing as quickly as possible.
We have been trying to get stuff into GCC Compiler Farm for years now.
There are a couple of boards IIRC. There are additional requirements
on the software side (well, distributions) that we couldn't provide
for quite some time.
I do know rackable systems will be limited -- there's one particular
component needed on the rackable systems that is in very short supply.
We've got multiple orders in, but quantities are limited and lead times
are absolutely insane.
FYI, I think, the new aarch64 builders are 8 core, 35G RAM and 8G
swap. The older machines had 8G/core setup. There seems to be 8 (?)
servers with 80 cores, but so far only 40-50 builders are enabled (no
overcommitting on CPU as that's not a great idea [based on my own
experience]).
I expect Veyron V1 to deliver a decent single and multi thread
performance, but we will need a lot of them. Probably 20-25 systems if
we assume a similar configuration as aarch64 builders (8-core, 32-64G
of RAM, 100-200G for storage). RAM and storage are cheap, but systems
will continue to be a problem. If we could somehow get to this level
we could stop investing into SBCs as they are stop-gap solutions for
builders.
Based on some guesses there isn't a lot of time either. I would love
to bootstrap CentOS Stream 10. It would be nice to have Fedora +
riscv64 in a good shape before that happens, but probably unrealistic.
Cheers,
david
7:46 a.m.
On Sun, Jan 8, 2023 at 2:42 AM David Abdurachmanov
<david.abdurachmanov(a)gmail.com> wrote:
On Sun, Jan 8, 2023 at 2:28 AM Jeff Law <jlaw(a)ventanamicro.com> wrote:
>
>
>
> On 1/6/23 23:41, David Abdurachmanov wrote:
> >
> > Summary from multi-year discussions/feedback on this:
> > - We don't have proper hardware to put into the data center that holds
> > servers used by Fedora infrastructure.
> Right. dev boards are not the solution here. It's got to be something
> that can be racked and with enough performance to matter.
>
> > - Not enough single and multi thread performance to avoid large impact
> > to Fedora development.
> Agreed. Returning to a situation like we had with armv7 isn't
> acceptable IMHO.
>
> >
> > Other than that Fedora/RISCV 37 is the first Fedora version to be
> > built fully natively using 20+ SiFive HiFive Unmatched boards. On a
> > good day we can keep up (if the builds aren't too large, e.g. GCC). We
> > don't really run Bodhi thus once package is built it's immediately
> > available. We run a very minimal setup right now (ideas to expand
> > that).
> It's fantastic we've got that far. But clearly it's not viable long
term.
Agreed. We have been cooking Fedora/RISCV since 2016, but we really
cannot move forward until the proper hardware (and things around it)
becomes available.
>
>
> > Another news is that Fedora/RISCV Koji server (
> > http://fedora.riscv.rocks/koji/ ) just moved into Fedora infra owned
> > server. We are about to start work on Fedora 38/Rawhide.
> Excellent. I'll have to update my chroots and containers as the F38
> bits start appearing.
I am still tweaking the server configuration, but I should be ready
for mass building soonish.
I might want to wait for GCC 13 to land in Rawhide, which should
happen soon (I think).
>
> >
> > 2023 is potentially a transition year. Ventana Veyron V1 Development
> > Platform looks good (I assume it has BMC). SOPHGO SG2042 should also
> > show up with 64-core @ 2.0GHz (T-HEAD C910) in early 2023 (?) I am not
> > yet convinced about their upstream support efforts (TBD).
> Yes Veyron-v1 will have a BMC and will be rackable. I have no
> significant insight into the T-HEAD efforts other than they do work a
> fair amount with VRULL on compiler and related technology.
I noticed that VRULL has been involved with T-HEAD on GCC and
potentially kernel side for a few months now. This makes them much
more optimistic about their SoC/HW support in general.
>
>
> >
> > If there is away to acquire Veyron V1 Development Platform I would be
> > interested to talk, and figure out what that would take. Such hardware
> > would be a game charger, and I do trust Ventana regarding upstream
> > support :)
> I'll be pushing to make systems available to Fedora and the GCC farm,
> but in general Ventana is more aligned towards Ubuntu. My goal is to
> have Fedora and Ubuntu on equal footing as quickly as possible.
We have been trying to get stuff into GCC Compiler Farm for years now.
There are a couple of boards IIRC. There are additional requirements
on the software side (well, distributions) that we couldn't provide
for quite some time.
>
> I do know rackable systems will be limited -- there's one particular
> component needed on the rackable systems that is in very short supply.
> We've got multiple orders in, but quantities are limited and lead times
> are absolutely insane.
FYI, I think, the new aarch64 builders are 8 core, 35G RAM and 8G
swap. The older machines had 8G/core setup. There seems to be 8 (?)
servers with 80 cores, but so far only 40-50 builders are enabled (no
overcommitting on CPU as that's not a great idea [based on my own
experience]).
I expect Veyron V1 to deliver a decent single and multi thread
performance, but we will need a lot of them. Probably 20-25 systems if
we assume a similar configuration as aarch64 builders (8-core, 32-64G
of RAM, 100-200G for storage). RAM and storage are cheap, but systems
will continue to be a problem. If we could somehow get to this level
we could stop investing into SBCs as they are stop-gap solutions for
builders.
Based on some guesses there isn't a lot of time either. I would love
to bootstrap CentOS Stream 10. It would be nice to have Fedora +
riscv64 in a good shape before that happens, but probably unrealistic.
It is very unlikely that CentOS Stream 10 will include RISC-V as a
fully included architecture. Perhaps via a CentOS Stream SIG.
josh
8:14 a.m.
On Mon, Jan 9, 2023 at 8:47 AM Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
On Sun, Jan 8, 2023 at 2:42 AM David Abdurachmanov
<david.abdurachmanov(a)gmail.com> wrote:
>
> On Sun, Jan 8, 2023 at 2:28 AM Jeff Law <jlaw(a)ventanamicro.com> wrote:
> >
> >
> >
> > On 1/6/23 23:41, David Abdurachmanov wrote:
> > >
> > > Summary from multi-year discussions/feedback on this:
> > > - We don't have proper hardware to put into the data center that
holds
> > > servers used by Fedora infrastructure.
> > Right. dev boards are not the solution here. It's got to be something
> > that can be racked and with enough performance to matter.
> >
> > > - Not enough single and multi thread performance to avoid large impact
> > > to Fedora development.
> > Agreed. Returning to a situation like we had with armv7 isn't
> > acceptable IMHO.
> >
> > >
> > > Other than that Fedora/RISCV 37 is the first Fedora version to be
> > > built fully natively using 20+ SiFive HiFive Unmatched boards. On a
> > > good day we can keep up (if the builds aren't too large, e.g. GCC).
We
> > > don't really run Bodhi thus once package is built it's
immediately
> > > available. We run a very minimal setup right now (ideas to expand
> > > that).
> > It's fantastic we've got that far. But clearly it's not viable
long term.
>
> Agreed. We have been cooking Fedora/RISCV since 2016, but we really
> cannot move forward until the proper hardware (and things around it)
> becomes available.
>
> >
> >
> > > Another news is that Fedora/RISCV Koji server (
> > > http://fedora.riscv.rocks/koji/ ) just moved into Fedora infra owned
> > > server. We are about to start work on Fedora 38/Rawhide.
> > Excellent. I'll have to update my chroots and containers as the F38
> > bits start appearing.
>
> I am still tweaking the server configuration, but I should be ready
> for mass building soonish.
> I might want to wait for GCC 13 to land in Rawhide, which should
> happen soon (I think).
>
> >
> > >
> > > 2023 is potentially a transition year. Ventana Veyron V1 Development
> > > Platform looks good (I assume it has BMC). SOPHGO SG2042 should also
> > > show up with 64-core @ 2.0GHz (T-HEAD C910) in early 2023 (?) I am not
> > > yet convinced about their upstream support efforts (TBD).
> > Yes Veyron-v1 will have a BMC and will be rackable. I have no
> > significant insight into the T-HEAD efforts other than they do work a
> > fair amount with VRULL on compiler and related technology.
>
> I noticed that VRULL has been involved with T-HEAD on GCC and
> potentially kernel side for a few months now. This makes them much
> more optimistic about their SoC/HW support in general.
>
> >
> >
> > >
> > > If there is away to acquire Veyron V1 Development Platform I would be
> > > interested to talk, and figure out what that would take. Such hardware
> > > would be a game charger, and I do trust Ventana regarding upstream
> > > support :)
> > I'll be pushing to make systems available to Fedora and the GCC farm,
> > but in general Ventana is more aligned towards Ubuntu. My goal is to
> > have Fedora and Ubuntu on equal footing as quickly as possible.
>
> We have been trying to get stuff into GCC Compiler Farm for years now.
> There are a couple of boards IIRC. There are additional requirements
> on the software side (well, distributions) that we couldn't provide
> for quite some time.
>
> >
> > I do know rackable systems will be limited -- there's one particular
> > component needed on the rackable systems that is in very short supply.
> > We've got multiple orders in, but quantities are limited and lead times
> > are absolutely insane.
>
> FYI, I think, the new aarch64 builders are 8 core, 35G RAM and 8G
> swap. The older machines had 8G/core setup. There seems to be 8 (?)
> servers with 80 cores, but so far only 40-50 builders are enabled (no
> overcommitting on CPU as that's not a great idea [based on my own
> experience]).
>
> I expect Veyron V1 to deliver a decent single and multi thread
> performance, but we will need a lot of them. Probably 20-25 systems if
> we assume a similar configuration as aarch64 builders (8-core, 32-64G
> of RAM, 100-200G for storage). RAM and storage are cheap, but systems
> will continue to be a problem. If we could somehow get to this level
> we could stop investing into SBCs as they are stop-gap solutions for
> builders.
>
> Based on some guesses there isn't a lot of time either. I would love
> to bootstrap CentOS Stream 10. It would be nice to have Fedora +
> riscv64 in a good shape before that happens, but probably unrealistic.
It is very unlikely that CentOS Stream 10 will include RISC-V as a
fully included architecture. Perhaps via a CentOS Stream SIG.
I believe that was the implication in the first place, hence
mentioning CentOS Stream rather than RHEL.
The Alternative Architectures SIG in CentOS would be where this would
happen. But the work needs to be done in Fedora first.
--
真実はいつも一つ！/ Always, there's only one truth!
8:20 a.m.
On 1/9/23 07:14, Neal Gompa wrote:
>
> It is very unlikely that CentOS Stream 10 will include RISC-V as a
> fully included architecture. Perhaps via a CentOS Stream SIG.
>
I believe that was the implication in the first place, hence
mentioning CentOS Stream rather than RHEL.
The Alternative Architectures SIG in CentOS would be where this would
happen. But the work needs to be done in Fedora first.
Hard to see a path for
CentOS and certainly not RHEL until after Fedora
is in better shape. Even then ISTM we need pull from sites looking to
deploy this stuff at scale.
jeff
9:22 a.m.
On Mon, Jan 9, 2023 at 9:15 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Mon, Jan 9, 2023 at 8:47 AM Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
>
> On Sun, Jan 8, 2023 at 2:42 AM David Abdurachmanov
> <david.abdurachmanov(a)gmail.com> wrote:
> >
> > On Sun, Jan 8, 2023 at 2:28 AM Jeff Law <jlaw(a)ventanamicro.com> wrote:
> > >
> > >
> > >
> > > On 1/6/23 23:41, David Abdurachmanov wrote:
> > > >
> > > > Summary from multi-year discussions/feedback on this:
> > > > - We don't have proper hardware to put into the data center that
holds
> > > > servers used by Fedora infrastructure.
> > > Right. dev boards are not the solution here. It's got to be
something
> > > that can be racked and with enough performance to matter.
> > >
> > > > - Not enough single and multi thread performance to avoid large
impact
> > > > to Fedora development.
> > > Agreed. Returning to a situation like we had with armv7 isn't
> > > acceptable IMHO.
> > >
> > > >
> > > > Other than that Fedora/RISCV 37 is the first Fedora version to be
> > > > built fully natively using 20+ SiFive HiFive Unmatched boards. On a
> > > > good day we can keep up (if the builds aren't too large, e.g.
GCC). We
> > > > don't really run Bodhi thus once package is built it's
immediately
> > > > available. We run a very minimal setup right now (ideas to expand
> > > > that).
> > > It's fantastic we've got that far. But clearly it's not
viable long term.
> >
> > Agreed. We have been cooking Fedora/RISCV since 2016, but we really
> > cannot move forward until the proper hardware (and things around it)
> > becomes available.
> >
> > >
> > >
> > > > Another news is that Fedora/RISCV Koji server (
> > > > http://fedora.riscv.rocks/koji/ ) just moved into Fedora infra owned
> > > > server. We are about to start work on Fedora 38/Rawhide.
> > > Excellent. I'll have to update my chroots and containers as the F38
> > > bits start appearing.
> >
> > I am still tweaking the server configuration, but I should be ready
> > for mass building soonish.
> > I might want to wait for GCC 13 to land in Rawhide, which should
> > happen soon (I think).
> >
> > >
> > > >
> > > > 2023 is potentially a transition year. Ventana Veyron V1 Development
> > > > Platform looks good (I assume it has BMC). SOPHGO SG2042 should also
> > > > show up with 64-core @ 2.0GHz (T-HEAD C910) in early 2023 (?) I am
not
> > > > yet convinced about their upstream support efforts (TBD).
> > > Yes Veyron-v1 will have a BMC and will be rackable. I have no
> > > significant insight into the T-HEAD efforts other than they do work a
> > > fair amount with VRULL on compiler and related technology.
> >
> > I noticed that VRULL has been involved with T-HEAD on GCC and
> > potentially kernel side for a few months now. This makes them much
> > more optimistic about their SoC/HW support in general.
> >
> > >
> > >
> > > >
> > > > If there is away to acquire Veyron V1 Development Platform I would
be
> > > > interested to talk, and figure out what that would take. Such
hardware
> > > > would be a game charger, and I do trust Ventana regarding upstream
> > > > support :)
> > > I'll be pushing to make systems available to Fedora and the GCC farm,
> > > but in general Ventana is more aligned towards Ubuntu. My goal is to
> > > have Fedora and Ubuntu on equal footing as quickly as possible.
> >
> > We have been trying to get stuff into GCC Compiler Farm for years now.
> > There are a couple of boards IIRC. There are additional requirements
> > on the software side (well, distributions) that we couldn't provide
> > for quite some time.
> >
> > >
> > > I do know rackable systems will be limited -- there's one particular
> > > component needed on the rackable systems that is in very short supply.
> > > We've got multiple orders in, but quantities are limited and lead
times
> > > are absolutely insane.
> >
> > FYI, I think, the new aarch64 builders are 8 core, 35G RAM and 8G
> > swap. The older machines had 8G/core setup. There seems to be 8 (?)
> > servers with 80 cores, but so far only 40-50 builders are enabled (no
> > overcommitting on CPU as that's not a great idea [based on my own
> > experience]).
> >
> > I expect Veyron V1 to deliver a decent single and multi thread
> > performance, but we will need a lot of them. Probably 20-25 systems if
> > we assume a similar configuration as aarch64 builders (8-core, 32-64G
> > of RAM, 100-200G for storage). RAM and storage are cheap, but systems
> > will continue to be a problem. If we could somehow get to this level
> > we could stop investing into SBCs as they are stop-gap solutions for
> > builders.
> >
> > Based on some guesses there isn't a lot of time either. I would love
> > to bootstrap CentOS Stream 10. It would be nice to have Fedora +
> > riscv64 in a good shape before that happens, but probably unrealistic.
>
> It is very unlikely that CentOS Stream 10 will include RISC-V as a
> fully included architecture. Perhaps via a CentOS Stream SIG.
>
I believe that was the implication in the first place, hence
mentioning CentOS Stream rather than RHEL.
Better to be clear about direction up-front, so thanks for clarifying.
"CentOS Stream" is used as both an umbrella term and a specific OS and
it causes confusion sometimes.
The Alternative Architectures SIG in CentOS would be where this
would
happen. But the work needs to be done in Fedora first.
Alternative Arches would totally make sense to me. And agreed Fedora
needs to land first.
josh
4:09 a.m.
On Mon, Jan 9, 2023 at 3:22 PM Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
On Mon, Jan 9, 2023 at 9:15 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
>
> On Mon, Jan 9, 2023 at 8:47 AM Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
> >
> > On Sun, Jan 8, 2023 at 2:42 AM David Abdurachmanov
> > <david.abdurachmanov(a)gmail.com> wrote:
> > >
> > > On Sun, Jan 8, 2023 at 2:28 AM Jeff Law <jlaw(a)ventanamicro.com>
wrote:
> > > >
> > > >
> > > >
> > > > On 1/6/23 23:41, David Abdurachmanov wrote:
> > > > >
> > > > > Summary from multi-year discussions/feedback on this:
> > > > > - We don't have proper hardware to put into the data center
that holds
> > > > > servers used by Fedora infrastructure.
> > > > Right. dev boards are not the solution here. It's got to be
something
> > > > that can be racked and with enough performance to matter.
> > > >
> > > > > - Not enough single and multi thread performance to avoid large
impact
> > > > > to Fedora development.
> > > > Agreed. Returning to a situation like we had with armv7 isn't
> > > > acceptable IMHO.
> > > >
> > > > >
> > > > > Other than that Fedora/RISCV 37 is the first Fedora version to
be
> > > > > built fully natively using 20+ SiFive HiFive Unmatched boards.
On a
> > > > > good day we can keep up (if the builds aren't too large,
e.g. GCC). We
> > > > > don't really run Bodhi thus once package is built it's
immediately
> > > > > available. We run a very minimal setup right now (ideas to
expand
> > > > > that).
> > > > It's fantastic we've got that far. But clearly it's not
viable long term.
> > >
> > > Agreed. We have been cooking Fedora/RISCV since 2016, but we really
> > > cannot move forward until the proper hardware (and things around it)
> > > becomes available.
> > >
> > > >
> > > >
> > > > > Another news is that Fedora/RISCV Koji server (
> > > > > http://fedora.riscv.rocks/koji/ ) just moved into Fedora infra
owned
> > > > > server. We are about to start work on Fedora 38/Rawhide.
> > > > Excellent. I'll have to update my chroots and containers as the
F38
> > > > bits start appearing.
> > >
> > > I am still tweaking the server configuration, but I should be ready
> > > for mass building soonish.
> > > I might want to wait for GCC 13 to land in Rawhide, which should
> > > happen soon (I think).
> > >
> > > >
> > > > >
> > > > > 2023 is potentially a transition year. Ventana Veyron V1
Development
> > > > > Platform looks good (I assume it has BMC). SOPHGO SG2042 should
also
> > > > > show up with 64-core @ 2.0GHz (T-HEAD C910) in early 2023 (?) I
am not
> > > > > yet convinced about their upstream support efforts (TBD).
> > > > Yes Veyron-v1 will have a BMC and will be rackable. I have no
> > > > significant insight into the T-HEAD efforts other than they do work
a
> > > > fair amount with VRULL on compiler and related technology.
> > >
> > > I noticed that VRULL has been involved with T-HEAD on GCC and
> > > potentially kernel side for a few months now. This makes them much
> > > more optimistic about their SoC/HW support in general.
> > >
> > > >
> > > >
> > > > >
> > > > > If there is away to acquire Veyron V1 Development Platform I
would be
> > > > > interested to talk, and figure out what that would take. Such
hardware
> > > > > would be a game charger, and I do trust Ventana regarding
upstream
> > > > > support :)
> > > > I'll be pushing to make systems available to Fedora and the GCC
farm,
> > > > but in general Ventana is more aligned towards Ubuntu. My goal is
to
> > > > have Fedora and Ubuntu on equal footing as quickly as possible.
> > >
> > > We have been trying to get stuff into GCC Compiler Farm for years now.
> > > There are a couple of boards IIRC. There are additional requirements
> > > on the software side (well, distributions) that we couldn't provide
> > > for quite some time.
> > >
> > > >
> > > > I do know rackable systems will be limited -- there's one
particular
> > > > component needed on the rackable systems that is in very short
supply.
> > > > We've got multiple orders in, but quantities are limited and lead
times
> > > > are absolutely insane.
> > >
> > > FYI, I think, the new aarch64 builders are 8 core, 35G RAM and 8G
> > > swap. The older machines had 8G/core setup. There seems to be 8 (?)
> > > servers with 80 cores, but so far only 40-50 builders are enabled (no
> > > overcommitting on CPU as that's not a great idea [based on my own
> > > experience]).
> > >
> > > I expect Veyron V1 to deliver a decent single and multi thread
> > > performance, but we will need a lot of them. Probably 20-25 systems if
> > > we assume a similar configuration as aarch64 builders (8-core, 32-64G
> > > of RAM, 100-200G for storage). RAM and storage are cheap, but systems
> > > will continue to be a problem. If we could somehow get to this level
> > > we could stop investing into SBCs as they are stop-gap solutions for
> > > builders.
> > >
> > > Based on some guesses there isn't a lot of time either. I would love
> > > to bootstrap CentOS Stream 10. It would be nice to have Fedora +
> > > riscv64 in a good shape before that happens, but probably unrealistic.
> >
> > It is very unlikely that CentOS Stream 10 will include RISC-V as a
> > fully included architecture. Perhaps via a CentOS Stream SIG.
> >
>
> I believe that was the implication in the first place, hence
> mentioning CentOS Stream rather than RHEL.
Better to be clear about direction up-front, so thanks for clarifying.
"CentOS Stream" is used as both an umbrella term and a specific OS and
it causes confusion sometimes.
Yes, that would be CentOS Stream SIG. There is interest in this.
> The Alternative Architectures SIG in CentOS would be where this would
> happen. But the work needs to be done in Fedora first.
Alternative Arches would totally make sense to me. And agreed Fedora
needs to land first.
Agreed. Doing some prediction based on the history, we have 2-3 Fedora
releases before CentOS Stream 10 might happen.
Without EPEL CentOS Stream (package wise) is not large. Of course the
majority (if not all) users consider EPEL an important part of the
experience.
Cheers,
david
>
> josh
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
4:25 a.m.
On Tue, Jan 10, 2023 at 5:11 AM David Abdurachmanov
<david.abdurachmanov(a)gmail.com> wrote:
On Mon, Jan 9, 2023 at 3:22 PM Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
>
> On Mon, Jan 9, 2023 at 9:15 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
> >
> > On Mon, Jan 9, 2023 at 8:47 AM Josh Boyer <jwboyer(a)fedoraproject.org>
wrote:
> > >
> > > On Sun, Jan 8, 2023 at 2:42 AM David Abdurachmanov
> > > <david.abdurachmanov(a)gmail.com> wrote:
> > > >
> > > > On Sun, Jan 8, 2023 at 2:28 AM Jeff Law <jlaw(a)ventanamicro.com>
wrote:
> > > > >
> > > > >
> > > > >
> > > > > On 1/6/23 23:41, David Abdurachmanov wrote:
> > > > > >
> > > > > > Summary from multi-year discussions/feedback on this:
> > > > > > - We don't have proper hardware to put into the data
center that holds
> > > > > > servers used by Fedora infrastructure.
> > > > > Right. dev boards are not the solution here. It's got to
be something
> > > > > that can be racked and with enough performance to matter.
> > > > >
> > > > > > - Not enough single and multi thread performance to avoid
large impact
> > > > > > to Fedora development.
> > > > > Agreed. Returning to a situation like we had with armv7
isn't
> > > > > acceptable IMHO.
> > > > >
> > > > > >
> > > > > > Other than that Fedora/RISCV 37 is the first Fedora version
to be
> > > > > > built fully natively using 20+ SiFive HiFive Unmatched
boards. On a
> > > > > > good day we can keep up (if the builds aren't too
large, e.g. GCC). We
> > > > > > don't really run Bodhi thus once package is built
it's immediately
> > > > > > available. We run a very minimal setup right now (ideas to
expand
> > > > > > that).
> > > > > It's fantastic we've got that far. But clearly it's
not viable long term.
> > > >
> > > > Agreed. We have been cooking Fedora/RISCV since 2016, but we really
> > > > cannot move forward until the proper hardware (and things around it)
> > > > becomes available.
> > > >
> > > > >
> > > > >
> > > > > > Another news is that Fedora/RISCV Koji server (
> > > > > > http://fedora.riscv.rocks/koji/ ) just moved into Fedora
infra owned
> > > > > > server. We are about to start work on Fedora 38/Rawhide.
> > > > > Excellent. I'll have to update my chroots and containers as
the F38
> > > > > bits start appearing.
> > > >
> > > > I am still tweaking the server configuration, but I should be ready
> > > > for mass building soonish.
> > > > I might want to wait for GCC 13 to land in Rawhide, which should
> > > > happen soon (I think).
> > > >
> > > > >
> > > > > >
> > > > > > 2023 is potentially a transition year. Ventana Veyron V1
Development
> > > > > > Platform looks good (I assume it has BMC). SOPHGO SG2042
should also
> > > > > > show up with 64-core @ 2.0GHz (T-HEAD C910) in early 2023
(?) I am not
> > > > > > yet convinced about their upstream support efforts (TBD).
> > > > > Yes Veyron-v1 will have a BMC and will be rackable. I have no
> > > > > significant insight into the T-HEAD efforts other than they do
work a
> > > > > fair amount with VRULL on compiler and related technology.
> > > >
> > > > I noticed that VRULL has been involved with T-HEAD on GCC and
> > > > potentially kernel side for a few months now. This makes them much
> > > > more optimistic about their SoC/HW support in general.
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > > If there is away to acquire Veyron V1 Development Platform
I would be
> > > > > > interested to talk, and figure out what that would take.
Such hardware
> > > > > > would be a game charger, and I do trust Ventana regarding
upstream
> > > > > > support :)
> > > > > I'll be pushing to make systems available to Fedora and the
GCC farm,
> > > > > but in general Ventana is more aligned towards Ubuntu. My goal
is to
> > > > > have Fedora and Ubuntu on equal footing as quickly as possible.
> > > >
> > > > We have been trying to get stuff into GCC Compiler Farm for years
now.
> > > > There are a couple of boards IIRC. There are additional requirements
> > > > on the software side (well, distributions) that we couldn't
provide
> > > > for quite some time.
> > > >
> > > > >
> > > > > I do know rackable systems will be limited -- there's one
particular
> > > > > component needed on the rackable systems that is in very short
supply.
> > > > > We've got multiple orders in, but quantities are limited and
lead times
> > > > > are absolutely insane.
> > > >
> > > > FYI, I think, the new aarch64 builders are 8 core, 35G RAM and 8G
> > > > swap. The older machines had 8G/core setup. There seems to be 8 (?)
> > > > servers with 80 cores, but so far only 40-50 builders are enabled
(no
> > > > overcommitting on CPU as that's not a great idea [based on my
own
> > > > experience]).
> > > >
> > > > I expect Veyron V1 to deliver a decent single and multi thread
> > > > performance, but we will need a lot of them. Probably 20-25 systems
if
> > > > we assume a similar configuration as aarch64 builders (8-core,
32-64G
> > > > of RAM, 100-200G for storage). RAM and storage are cheap, but
systems
> > > > will continue to be a problem. If we could somehow get to this level
> > > > we could stop investing into SBCs as they are stop-gap solutions for
> > > > builders.
> > > >
> > > > Based on some guesses there isn't a lot of time either. I would
love
> > > > to bootstrap CentOS Stream 10. It would be nice to have Fedora +
> > > > riscv64 in a good shape before that happens, but probably
unrealistic.
> > >
> > > It is very unlikely that CentOS Stream 10 will include RISC-V as a
> > > fully included architecture. Perhaps via a CentOS Stream SIG.
> > >
> >
> > I believe that was the implication in the first place, hence
> > mentioning CentOS Stream rather than RHEL.
>
> Better to be clear about direction up-front, so thanks for clarifying.
> "CentOS Stream" is used as both an umbrella term and a specific OS and
> it causes confusion sometimes.
Yes, that would be CentOS Stream SIG. There is interest in this.
>
> > The Alternative Architectures SIG in CentOS would be where this would
> > happen. But the work needs to be done in Fedora first.
>
> Alternative Arches would totally make sense to me. And agreed Fedora
> needs to land first.
Agreed. Doing some prediction based on the history, we have 2-3 Fedora
releases before CentOS Stream 10 might happen.
Without EPEL CentOS Stream (package wise) is not large. Of course the
majority (if not all) users consider EPEL an important part of the
experience.
There is precedent for the AltArch SIG to rebuild EPEL for an
alternative architecture. I think the way it would be done today would
necessarily need to be different from how it was done in the times we
build 32-bit x86 and ARM support with CentOS 7, but it's absolutely doable.
--
真実はいつも一つ！/ Always, there's only one truth!
7:02 a.m.
On Tue, Jan 10, 2023 at 5:11 AM David Abdurachmanov
<david.abdurachmanov(a)gmail.com> wrote:
On Mon, Jan 9, 2023 at 3:22 PM Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
>
> On Mon, Jan 9, 2023 at 9:15 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
> >
> > On Mon, Jan 9, 2023 at 8:47 AM Josh Boyer <jwboyer(a)fedoraproject.org>
wrote:
> > >
> > > On Sun, Jan 8, 2023 at 2:42 AM David Abdurachmanov
> > > <david.abdurachmanov(a)gmail.com> wrote:
> > > >
> > > > On Sun, Jan 8, 2023 at 2:28 AM Jeff Law <jlaw(a)ventanamicro.com>
wrote:
> > > > >
> > > > >
> > > > >
> > > > > On 1/6/23 23:41, David Abdurachmanov wrote:
> > > > > >
> > > > > > Summary from multi-year discussions/feedback on this:
> > > > > > - We don't have proper hardware to put into the data
center that holds
> > > > > > servers used by Fedora infrastructure.
> > > > > Right. dev boards are not the solution here. It's got to
be something
> > > > > that can be racked and with enough performance to matter.
> > > > >
> > > > > > - Not enough single and multi thread performance to avoid
large impact
> > > > > > to Fedora development.
> > > > > Agreed. Returning to a situation like we had with armv7
isn't
> > > > > acceptable IMHO.
> > > > >
> > > > > >
> > > > > > Other than that Fedora/RISCV 37 is the first Fedora version
to be
> > > > > > built fully natively using 20+ SiFive HiFive Unmatched
boards. On a
> > > > > > good day we can keep up (if the builds aren't too
large, e.g. GCC). We
> > > > > > don't really run Bodhi thus once package is built
it's immediately
> > > > > > available. We run a very minimal setup right now (ideas to
expand
> > > > > > that).
> > > > > It's fantastic we've got that far. But clearly it's
not viable long term.
> > > >
> > > > Agreed. We have been cooking Fedora/RISCV since 2016, but we really
> > > > cannot move forward until the proper hardware (and things around it)
> > > > becomes available.
> > > >
> > > > >
> > > > >
> > > > > > Another news is that Fedora/RISCV Koji server (
> > > > > > http://fedora.riscv.rocks/koji/ ) just moved into Fedora
infra owned
> > > > > > server. We are about to start work on Fedora 38/Rawhide.
> > > > > Excellent. I'll have to update my chroots and containers as
the F38
> > > > > bits start appearing.
> > > >
> > > > I am still tweaking the server configuration, but I should be ready
> > > > for mass building soonish.
> > > > I might want to wait for GCC 13 to land in Rawhide, which should
> > > > happen soon (I think).
> > > >
> > > > >
> > > > > >
> > > > > > 2023 is potentially a transition year. Ventana Veyron V1
Development
> > > > > > Platform looks good (I assume it has BMC). SOPHGO SG2042
should also
> > > > > > show up with 64-core @ 2.0GHz (T-HEAD C910) in early 2023
(?) I am not
> > > > > > yet convinced about their upstream support efforts (TBD).
> > > > > Yes Veyron-v1 will have a BMC and will be rackable. I have no
> > > > > significant insight into the T-HEAD efforts other than they do
work a
> > > > > fair amount with VRULL on compiler and related technology.
> > > >
> > > > I noticed that VRULL has been involved with T-HEAD on GCC and
> > > > potentially kernel side for a few months now. This makes them much
> > > > more optimistic about their SoC/HW support in general.
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > > If there is away to acquire Veyron V1 Development Platform
I would be
> > > > > > interested to talk, and figure out what that would take.
Such hardware
> > > > > > would be a game charger, and I do trust Ventana regarding
upstream
> > > > > > support :)
> > > > > I'll be pushing to make systems available to Fedora and the
GCC farm,
> > > > > but in general Ventana is more aligned towards Ubuntu. My goal
is to
> > > > > have Fedora and Ubuntu on equal footing as quickly as possible.
> > > >
> > > > We have been trying to get stuff into GCC Compiler Farm for years
now.
> > > > There are a couple of boards IIRC. There are additional requirements
> > > > on the software side (well, distributions) that we couldn't
provide
> > > > for quite some time.
> > > >
> > > > >
> > > > > I do know rackable systems will be limited -- there's one
particular
> > > > > component needed on the rackable systems that is in very short
supply.
> > > > > We've got multiple orders in, but quantities are limited and
lead times
> > > > > are absolutely insane.
> > > >
> > > > FYI, I think, the new aarch64 builders are 8 core, 35G RAM and 8G
> > > > swap. The older machines had 8G/core setup. There seems to be 8 (?)
> > > > servers with 80 cores, but so far only 40-50 builders are enabled
(no
> > > > overcommitting on CPU as that's not a great idea [based on my
own
> > > > experience]).
> > > >
> > > > I expect Veyron V1 to deliver a decent single and multi thread
> > > > performance, but we will need a lot of them. Probably 20-25 systems
if
> > > > we assume a similar configuration as aarch64 builders (8-core,
32-64G
> > > > of RAM, 100-200G for storage). RAM and storage are cheap, but
systems
> > > > will continue to be a problem. If we could somehow get to this level
> > > > we could stop investing into SBCs as they are stop-gap solutions for
> > > > builders.
> > > >
> > > > Based on some guesses there isn't a lot of time either. I would
love
> > > > to bootstrap CentOS Stream 10. It would be nice to have Fedora +
> > > > riscv64 in a good shape before that happens, but probably
unrealistic.
> > >
> > > It is very unlikely that CentOS Stream 10 will include RISC-V as a
> > > fully included architecture. Perhaps via a CentOS Stream SIG.
> > >
> >
> > I believe that was the implication in the first place, hence
> > mentioning CentOS Stream rather than RHEL.
>
> Better to be clear about direction up-front, so thanks for clarifying.
> "CentOS Stream" is used as both an umbrella term and a specific OS and
> it causes confusion sometimes.
Yes, that would be CentOS Stream SIG. There is interest in this.
>
> > The Alternative Architectures SIG in CentOS would be where this would
> > happen. But the work needs to be done in Fedora first.
>
> Alternative Arches would totally make sense to me. And agreed Fedora
> needs to land first.
Agreed. Doing some prediction based on the history, we have 2-3 Fedora
releases before CentOS Stream 10 might happen.
CentOS Stream 10 is actively in development under the ELN project in
Fedora right now. My suggestion would be to just work in Fedora and
pay attention to ELN as well if CentOS Stream SIGs, CentOS Stream,
and/or RHEL are eventual goals. That is to say, don't try to guess
the timing of a new CentOS Stream kicking off, because you'll likely
guess incorrectly and there's no reason to with ELN. :)
Without EPEL CentOS Stream (package wise) is not large. Of course
the
majority (if not all) users consider EPEL an important part of the
experience.
ELN Extras also covers at least a subset of what will be the next EPEL.
josh
1:33 p.m.
Hi,
On Monday, 2021-10-04 13:03:27 -0400, Matthew Miller wrote:
But beyond that: What other things might be limits? Are there key
bits of
the distro which don't build yet?
Fwiw, I learned just yesterday that apparently to stay on the cheap side
they underspecified RISC-V FPU to omit some IEEE 754 optional behaviour
that would preserve and propagate a quiet NaN's payload in floating
point calculations. It may or may not (optionally) be supported on
a given RISC-V architecture.
That is a feature LibreOffice Calc makes heavy use of to transport error
information in doubles, where without those payload details it would
result in just a general NaN error for illegal FP operation.
Some other software may also use NaN payloads (R is mentioned in the
IEEE 754 .pdf on NaNs
https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/background/nan...
("Known and possible uses of NaN payloads"), and JavaScript NaN-boxing
for type of data).
Further pointers in
https://bugs.documentfoundation.org/show_bug.cgi?id=152943
Eike
--
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
4:58 p.m.
This is exciting news related to the RISC-V ecosystem.
I expect that the RISC-V Software Ecosystem (RISE) Project will be a
leading organization to help open source projects by providing free
RISC-V CI services to them, and sponsoring the free RISC-V SSH servers
on the clouds to them. It is like what Works on Arm organization[1]
has currently been doing for the Arm ecosystem.
Industry Leaders Launch RISE to Accelerate the Development of Open
Source Software for RISC-V
https://linuxfoundation.eu/newsroom/rise-project-launches-to-accelerate-d...
[1] https://www.arm.com/markets/computing-infrastructure/works-on-arm
--
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See <https://www.worldtimebuddy.com/czech-republic-prague-to-utc> for
the timezone.
3:12 a.m.
On Wed, May 31, 2023 at 11:58:57PM +0200, Jun Aruga (he / him) wrote:
This is exciting news related to the RISC-V ecosystem.
I expect that the RISC-V Software Ecosystem (RISE) Project will be a
leading organization to help open source projects by providing free
RISC-V CI services to them, and sponsoring the free RISC-V SSH servers
on the clouds to them. It is like what Works on Arm organization[1]
has currently been doing for the Arm ecosystem.
Industry Leaders Launch RISE to Accelerate the Development of Open
Source Software for RISC-V
https://linuxfoundation.eu/newsroom/rise-project-launches-to-accelerate-d...
[1] https://www.arm.com/markets/computing-infrastructure/works-on-arm
Red Hat is a member. In fact there's an (internal) kick-off meeting
for RISE today which I'll be attending.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
4:07 a.m.
Red Hat is a member. In fact there's an (internal) kick-off
meeting
for RISE today which I'll be attending.
I saw that Red Hat is a member of the RISE project on the page.
And it's really great to see that you will be attending the kick-off
meeting. Thank you for that. I am looking forward to seeing your
updates about it if you have something to share publicly. It's a great
step of the RISC-V to be a first class in Fedora Linux.
--
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See <https://www.worldtimebuddy.com/czech-republic-prague-to-utc> for
the timezone.
7:14 p.m.
Can't wait for a risc-v Fedora iso for Workstation!
https://fedoraproject.org/workstation/download/ here
312
days inactive
928
days old
40 comments
20 participants
participants (20)
-
Al Stone -
David Abdurachmanov -
Dominik 'Rathann' Mierzejewski -
Eike Rathke -
Fabio Valentini -
Jeff Law -
Josh Boyer -
Josh Stone -
JT -
Jun Aruga (he / him) -
Justin Forbes -
Kevin Fenzi -
Leigh Scott -
linux guy -
Luna Jernberg -
Matthew Miller -
Neal Gompa -
Reon Beon -
Richard W.M. Jones -
Zamir SUN