[maemo-developers] sbox2 & maemo

[From: Marius Vollmer]

"ext Lauri Leukkunen" <lle at rahina.org> writes:

> At least it should be possible to build a package for both host and
> target distros like this:
>
> cd my_package
> dpkg-buildpackage -rfakeroot
> sb2 dpkg-buildpackage -rfakeroot

Hmm, I am still quite fuzzy about what SB2 is all about.  Maybe you
can hep me out a bit.

>From my point of view, the host and target distributions should be as
independent as possible.  The host could be Debian, or Redhat, or
Nokia's internal Linux, or OSX, or even Windows.

The target distribution right now is the existing maemo mess, but we
could collectively move to Debian or Ubuntu.  In any case, people
might use whatever host OS works for them, but would work all on the
same target distribution.

The SB2 idea seems to be that there is only one distribution, and SB2
is a clever hack to allow you to compile for a different target
architecture than the host one without having to worry about
cross-compilation complexities too much.

Thus, from what I understand about SB2, I would characterize the
situation so that the "sb2" command takes you from the host
architecture to the target architecture, but stays in the same
distribution.  The host and target architecture environments are
separate installations of this one distribution, and you need to make
sure that both of them are properly up-to-date and syncronized.

Programs that run inside the target architecture environment get a
native environment to run in and a properly emulated CPU to run on.
Thus, they never know that they are effectively being cross-compiled.
This is too slow for some programs like the compiler, so here comes
the clever part of SB2: there is a conceptual second layer of
emulation that emulates the host architecture on the target
architecture with the magical property that the two layers of
emulation cancel each other out and performance actually increases.

This second layer of emulation makes use of the programs installed in
the host distribution.  This is the reason why everybody needs to
agree on the host distribution as well as on the target distribution,
but the two distributions don't need to be the same for this reason.

The two distributions need to be the same since the host distribution
is directly used for development of the same software that is compiled
in the target architecture environment.  The host environment is much
nicer for testing and debugging, since the SB2 emulation is good
enough for compiling, but not for really booting and running the
distribution.

This is a good and simple model, the only thing I don't like about it
is that I can't choose or configure my host environment independently
from the target environment.

There are two kinds of borders: one kind isolates OSs from each other;
this could be done with some virtualization tool like xen, uml, or
maybe chroot.  The other kind isolates different architectures within
the same distribution; this is what SB2 does.

In order for me to use SB2 and still retain control over my host OS, I
would have to install the OS that SB2 wants as its host inside a
virtual machine.  That's not a problem, of course.  I think I found my
weekend project...

[ There is another picture in my head that I think might work: we keep
  the current SB1 setup but instead of having SB1 redirect tools into
  devkits, it redirects tools into a second target.  That second
  target can then be maintained in the usual way.  But I like the
  full-virtualization approach much better than the half-assed SB1
  emulation.
]

So, in the end, I think it's actually all quite simple: we make a OS
that runs on real x86 hardware, inside Xen on x86 and on a Internet
Tablet arm device and can be used both as a development environment as
well as the basis for IT OS.  That OS includes sb2 which is used to
'cross-compile' software from i386 to armel.

As a bonus, we could extend the range of supported hardware platforms
(Xen on PowerPC, Intels x86 mobile platform, sb2 from powerpc to
i386...)

Debian GNU/Linux is pretty close to these requirements: it doesn't run
on Internet Tablets yet and it probably can't be the basis for IT OS
if it would.  Both issues should be straightforward to address.  (I
hope I don't have to explain why they are worth addressing. :-)