Date: Sun, 17 Jul 2022 21:25:58 +0000 From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 265241] Runaway builds on armv6, armv7 in port cad/iverilog Message-ID: <bug-265241-29464-aRgjbrQjpi@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-265241-29464@https.bugs.freebsd.org/bugzilla/> References: <bug-265241-29464@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D265241 --- Comment #18 from Mark Millard <marklmi26-fbsd@yahoo.com> --- (In reply to Ed Maste from comment #17) Cool. Then, is there a reason that the problematical qemu technique of covering the building armv7 ports is still in use instead of having some eMAG(s) use a armv7 poudriere jail? Treating armv6 as less important at this stage . . . why . . . Covering armv6 as well (without qemu use) gets into having an alternate kernel that is based on instead using: #define MACHINE_ARCH32 "armv6" in sys/arm64/include/param.h . That would make it a boot-kernel choice for which of armv7 vs. armv6 can be done without qemu --and a matching poudriere jail could be used for armv6 when booted for armv6 support. But, not a likely way to set up/handle a build server. Having an eMAG permanently with such a special kernel could limit its other uses. So, likely, just armv7 coverage (the default MACHINE_ARCH32) via an armv7 poudriere jail. (I had some notes on this from having helped someone establish an armv6 poudriere jail context, where they could reasonably control the boot-kernel via reboots as needed and they could build both styles of kernels for themselves.) --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-265241-29464-aRgjbrQjpi>