From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59661) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTzSF-0001xZ-3w for qemu-devel@nongnu.org; Sun, 21 Apr 2013 14:57:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UTzSD-0004u1-Rf for qemu-devel@nongnu.org; Sun, 21 Apr 2013 14:57:39 -0400 Received: from mail-qc0-x22c.google.com ([2607:f8b0:400d:c01::22c]:56267) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTzSD-0004tl-NI for qemu-devel@nongnu.org; Sun, 21 Apr 2013 14:57:37 -0400 Received: by mail-qc0-f172.google.com with SMTP id b25so2227246qca.3 for ; Sun, 21 Apr 2013 11:57:36 -0700 (PDT) Date: Sun, 21 Apr 2013 00:37:14 -0500 From: Rob Landley In-Reply-To: (from blauwirbel@gmail.com on Sat Apr 20 05:36:46 2013) Message-Id: <1366522634.18069.129@driftwood> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Target-agnostic virtio? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel , Artyom Tarasenko On 04/20/2013 05:36:46 AM, Blue Swirl wrote: > > I plan to add a sparc64 target built from source to Aboriginal =20 > Linux. > > > > For a lot of the 64-bit targets, actual 64 bit userspace support is > > strangely lacking. For ppc64 they say to use ppc32, and I've been =20 > told that > > about sparc64 as well. I don't know if this is an optimization or a > > requirement. I have a 32 bit image, I'd like to test the 64 bit =20 > codepaths as > > well... >=20 > It's a sort of optimization, the pointers are smaller. OpenBSD/sparc64 > takes a different approach, every binary is 64 bits. Would it be hard > to make Aboriginal *BSD? ;-) Not _that_ hard, but I'm not sure it's interesting? Aboriginal Linux is basically 7 packages: linux, gcc, binutils, uClibc, =20 make, bash, and busybox. (I also add distcc so the native toolchain can =20 move some of the heavy lifting of compilation outside the emulator, but =20 that's optional.) This is the smallest system capable of not only rebuilding itself under =20 itself, but building Linux From Scratch under the result (and thus =20 natively bootstrapping up to an arbitrary set of packages). I'm gradually replacing busybox with toybox, and I'm migrating from =20 uClibc to musl. I vaguely plan to read the various klibc arch support =20 bits to add new architectures to musl, but my day job doesn't have =20 anything to do with my hobby programming so there's a chronic shortage =20 of time, and toybox 1.0 is my priority right now for reasons I blatered =20 at length about at ELC a month or so back (http://youtu.be/SGmtP5Lg_t0). In theory swapping in a bsd kernel and libc, and beating the toolchain =20 into accepting it, might not be too hard. But what I'm more likely to =20 do is try to add sparc64 support to musl and convince the toolchain =20 it's just going to have to cope with the idea of a 64 bit sparc =20 userspace. Rob =