> On May 23, 2015, at 5:26 PM, Scarlett <scarlett@entering.space> wrote: > >> On 23/05/2015 22:19, Douglas Beattie wrote: >> I think there is a difference between building OpenBSD "on real hardware" >> and building port binaries for ARMv7 which are intended to run across all >> of the ARMv7 target ports. >> >> And I think the concern should be less about “OS bugs and emulator bugs” >> since (1.) you’re not building the OS, and (2.) ARM emulation is quite mature >> with several standard platform configurations which may be targeted >> (including >> ARMv7). >> >> A dual-Xeon-quad-core server (8 cores, 16 threads) with 48G of RAM can >> easily host 10 or more VMs, and do a distributed build across QEMU/ARM >> running on each of the VMs. The resulting compiled code for a port ‘binary’ >> distribution should be no different regardless of where it was actually >> built. >> >> So, what then is the reason (other than philosophical) that an OpenBSD port >> does not yet exist for QEMU/ARM ? If you can no longer blame the hardware >> to such a degree, then either your port builds should become more reliable, >> or >> there is still a problem with the OS arch. >> >> The behavior of emulated hardware is repeatable and fairly predictable, >> especially >> if it’s a mature emulation platform (i.e. having been pounded on and >> considered >> stable already for multiple OS). Taking the hardware (excuse) out of the >> equation, >> you could move forward with efforts to continuously build and validate ARMv7 >> ports >> with every iteration of OpenBSD. >> >> And yes, the native building of the OS itself is still a great stress test >> for these up-and- >> coming ARMv7 hardware platforms. But the building of port packages -- or the >> choice >> of making excuses to not build or provide them -- is really a very separate >> issue. >> >> >>> On 2015-05-23, Stuart Henderson wrote: >>> Not particularly. If the machines and/or OS arch are reliable in the >>> first place it's not a problem to spread builds across more machines. >>> But in reality, it's not very reliable, so 1) adding machines just >>> means babysitting additional crashes, and 2) if emulation is used >>> instead of real machines, then you're dealing with both OS bugs and >>> emulator bugs. > > Why are OS bugs not a concern when doing ports builds? The OS must be > suitably stable to complete the build, unless you're advocating for > cross-compilation. I could point to NetBSD's history with toolchain bugs and > cross-built executables not actually running on the target platform as being > valid reasons for avoiding it. It's probably unfair to single out NetBSD > here, plenty of other projects have had these headaches. > > I think the reason for there being no arm-on-qemu support is the usual > supect: it's not a priority for any developer. > > Maybe it's easy to accuse others of making excuses when you aren't > responsible for making sure the builds work and aren't hacking on the port. > > (whoops, I forgot to CC the list). >
Building virtual is a solid idea. It's just not fun, so it's not going to happen. Hell, Qemu support is likely going to be easier than real hardware.
