> On Nov 24, 2015, at 11:55 PM, Eero Tamminen <[email protected]> wrote: >> Not really possible to keep the Aranyms. They take up space in my >> office which I and especially my boss want to get rid of. The qemu-m68k >> stuff can be easily set up on our VMWare cluster. > > Why Aranym emulator takes office space and cannot be run in VMs? > Or did you mean real HW?
Aranym is a bit more complicated than just using qemu-user-static plus sbuild. For Aranym, I first need to run a X server to set up the system. You cannot configure Aranym headless. Secondly, you need a manual, more complicated network configuration as compared to qemu which requires nothing in this regard. Considering that my university has a special network configuration for the Linux hosts, everything that requires extra configuration is rather bad. To run Aranym, I basically need a Debian machine which is manually installed and configured, while for qemu, I can just spin up four VMWare machines, make a fully automatic installation (FAI) over the network and set up and configure qemu plus sbuild. This means much less adminstration work for me and makes my boss much happier because I spent less time on these things and since the buildds run "our Linux", they can be much easier maintained within the IT department. Don't forget, I am not hosting this at home but at my university where I work. And I am already hosting way too many buildds. Thus, I should try to keep the maintenance overhead as low as possible and make sure that the machines adhere to the IT guidelines of my employer. Given that I currently host nine m68k buildds, one sh4 buildd, one x32 buildd and one huge HP desktop which hosts four hppa buildds, I don't think I really need to defend myself here. This doesn't include the extra work I spend on sparc64 even. My university also donated two rather expensive SFF SAS drives for the sparc64 buildd I maintain in Hungary. >>> I think the instruction emulation is at the same level as Aranym, but >>> the qemu linux-user part has some issues with multi-threaded applications. >> >> Well, we'll see how it goes. Packages like gcc-5 and systemd build fine, >> so I am not too scared. For pure building, qemu-m68k is a very good >> alternative. > > Btw. Nokia's "Debian based" Maemo distro used qemu for running > any necessary native code during cross-builds. All code for > it was cross-built (to ARM, before Debian supported given ARM > versions), same was with Nokia's Harmattan/MeeGo that followed > Maemo. It worked fine until Nokia stopped doing Linux based > phones/tablets. qemu-arm still works fine and Google uses it for its Android emulator, don't they? > Besides threading (and unimplemented syscalls + bugs), one more > issue was /proc/ files. I guess e.g. /proc/PID/auxv HW capability > leakage from host is nowadays plugged in user-space Qemu and > provides suitable values for m68k? > > Threading part can mean that you get random problems, e.g. with > threaded test-suites (gstreamer?), that are run as part of build > process. While the other issues are fixable in user-space Qemu, > AFAIK the threading issue really isn't. :-/ I haven't really run into any bigger issues yet. Some packages got stuck during build, but that's all really. If you want to have things improved, you're very welcome to help. Adrian
