[Aboriginal] [PATCH] Move i586 to virtio

[Rob Landley]

Alas, the work week's started again so my free time is in much smaller
chunks...

On 06/27/2011 10:17 AM, Alessio Igor Bogani wrote:
> Rob,
> 
> 2011/6/27 Rob Landley <rob at landley.net>:
>> On 06/22/2011 04:46 AM, Alessio Igor Bogani wrote:
>>> # HG changeset patch
>>> # User Alessio Igor Bogani <alessioigorbogani at gmail.com>
>>> # Date 1308735970 -7200
>>> # Node ID 9cb1d126a6102d47f3266a148247c97758a01bfd
>>> # Parent  67accb5d252602b3b2ad2d0b8aa6fd9a62c74030
>>> Move i586 to virtio
>>
>> I moved this to i686-kvm target.  Could you test if it works for you?
> 
> Unfortunately it doesn't work on my system:
> [...]
> Root device is (9, 0)
> Setup is 12940 bytes (padded to 13312 bytes).
> System is 1378 kB
> CRC e329e245
> Kernel: arch/x86/boot/bzImage is ready  (#1)
> 
> Exiting due to errors (i686-kvm linux-kernel linux)
> [...]

The kernel built successfully and then exited due to errors?  That's odd...

> The ls build/ reports:
> linux-kernel-i686-kvm
> root-image-i686-kvm.tar.bz2
> simple-cross-compiler-i686-kvm.tar.bz2
> simple-root-filesystem-i686-kvm.tar.bz2

All of these should be symlinks to the base architecture (the equivalent
-i686 versions).

A base architecure is the target we have the same compiler as, meaning
the arch tuple, compiler flags, and uClibc config are all the same.  In
that case there's no point in rebuilding that stuff, we should just use
the existing version.

You'll want to do an ls -l on build to see what you actually have.

Ah, I didn't test the dependencies if the base isn't built yet.  In that
case it should build the base version and create a symlink to it.
Hmmm...  yeah, that could break stuff.  I'll have to try that when I get
a moment...

> packages
> root-image-i686.tar.bz2
> simple-cross-compiler-i686.tar.bz2
> simple-root-filesystem-i686.tar.bz2
> root-image-i686        simple-cross-compiler-i686
> simple-root-filesystem-i686             temp-i686-kvm
> root-image-i686-kvm    simple-cross-compiler-i686-kvm
> simple-root-filesystem-i686-kvm
> 
> Strange thing seem happens building kernel (please note that
> "linux-kernel-i686-kvm" is a directory which I suspect should be named
> "linux-kernel-i686" instead).

There is a linux-kernel-i686 already.  That's the base architecture, and
its kernel/qemu config emulates actual hardware (IDE drive and such).

In the real world there are often several different boards that use the
same compiler and root filesystem but need different kernel .configs and
bootloaders and such.  I've had some support for that for a while
through the "hardware target" (hw- prefix) stuff, with the Tin Can Tools
Hammer board being an example (derived from the armv4tl base architecture).

But this support was always a hack, and I was never happy with the
design, and it bit-rotted for lack of testing.  I'm trying to fix it now.

It seems to me that i686 with virtio support is the same sort of variant
of the i686 base architecture: the compiler and root filesystem are the
same as a "real hardware" version, but the kernel config and the
environment you run it in differ.  So I'm trying to get it to work
again, but this time the distinguishing factor isn't a magic prefix on
the name, but for base architectures the target is a file, and for
variants of those architectures the target is a directory.  (That way
buildall.sh knows to build all the base architectures and can skip the
variants, but build.sh can build whichever one you tell it to and lists
all of them.)

Part of the reason for doing this is variants need their own kernel
.config, and you have an existing .config and just want to use that
without messing with miniconfig or baseconfig.  So this gives a
directory to drop that in.  (I'll probably change the name it looks for
to "linux-config" or something similarly obvious.)

There are still rough edges to this design.  I like most target configs
being a single file now that it's cleaned up enough for that to work,
but supplying an external kernel .config breaks that.  I had an existing
hw- target distinction which was always a sore spot, using the
file/directory distinction to indicate that makes more sense.  It's
still a bit "black magic" though, I need to at least document it a lot
better once I get the kinks worked out.

As always, if you have design suggestions I'm happy to hear 'em.  Making
this stuff simple is _hard_,  Making it do 8000 conflicting things is
easy, making the result SIMPLE rather than a giant pile of special cases
that collapses under its' own weight: that's hard.

> In any case I would called that i686-virt or i686-virtio instead of
> i686-kvm. The most important part is the use of virtio devices where
> the kvm is only a secondary optimization handled by the system so I
> would used qemu (instead of kvm) in run_emulator() .

*shrug*  I can call it i686-virtio if you prefer, sure.

But more importantly, I need to figure out why it didn't build for you,
and fix it...

> Ciao,
> Alessio

Rob