"ext Lauri Leukkunen" <[EMAIL PROTECTED]> 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. :-) _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
