From: Rob Landley <rob@landley.net>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: qemu-devel <qemu-devel@nongnu.org>,
Artyom Tarasenko <atar4qemu@gmail.com>
Subject: Re: [Qemu-devel] Target-agnostic virtio?
Date: Sun, 21 Apr 2013 00:37:14 -0500 [thread overview]
Message-ID: <1366522634.18069.129@driftwood> (raw)
In-Reply-To: <CAAu8pHtF6WYMRwfbGiVHuYEqJv6RXbOywt=dKrtMYgmeG9RXDg@mail.gmail.com> (from blauwirbel@gmail.com on Sat Apr 20 05:36:46 2013)
On 04/20/2013 05:36:46 AM, Blue Swirl wrote:
> > I plan to add a sparc64 target built from source to Aboriginal
> 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
> 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
> codepaths as
> > well...
>
> 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,
make, bash, and busybox. (I also add distcc so the native toolchain can
move some of the heavy lifting of compilation outside the emulator, but
that's optional.)
This is the smallest system capable of not only rebuilding itself under
itself, but building Linux From Scratch under the result (and thus
natively bootstrapping up to an arbitrary set of packages).
I'm gradually replacing busybox with toybox, and I'm migrating from
uClibc to musl. I vaguely plan to read the various klibc arch support
bits to add new architectures to musl, but my day job doesn't have
anything to do with my hobby programming so there's a chronic shortage
of time, and toybox 1.0 is my priority right now for reasons I blatered
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
into accepting it, might not be too hard. But what I'm more likely to
do is try to add sparc64 support to musl and convince the toolchain
it's just going to have to cope with the idea of a 64 bit sparc
userspace.
Rob
next prev parent reply other threads:[~2013-04-21 18:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-26 0:52 [Qemu-devel] Target-agnostic virtio? Rob Landley
2013-03-26 1:24 ` Richard Henderson
2013-03-26 3:55 ` Rob Landley
2013-03-26 7:34 ` Artyom Tarasenko
2013-04-13 17:03 ` Rob Landley
2013-04-14 9:38 ` Artyom Tarasenko
2013-04-14 9:59 ` Mark Cave-Ayland
2013-04-14 19:49 ` Artyom Tarasenko
2013-04-15 17:21 ` Rob Landley
2013-04-17 2:15 ` Rob Landley
2013-04-20 10:36 ` Blue Swirl
2013-04-21 5:37 ` Rob Landley [this message]
2013-04-27 20:00 ` Artyom Tarasenko
2013-04-29 5:43 ` Rob Landley
2013-04-30 21:31 ` Artyom Tarasenko
2013-05-01 17:12 ` Rob Landley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1366522634.18069.129@driftwood \
--to=rob@landley.net \
--cc=atar4qemu@gmail.com \
--cc=blauwirbel@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).