2011/10/12 Eero Tamminen <[email protected]>: > Hi, > > On 10/12/2011 10:56 AM, ext Carsten Munk wrote: >> >> 2011/10/11 Eero Tamminen<[email protected]>: >> When this was working, statistics were done to identify where there >> could be a benefit of accelerating certain binaries by making them X86 >> specific. The approach was simple: to make a 'fast' ARM build machine >> without the disadvantages of Scratchbox1 (fairly static toolset, >> difficult to maintain). - as well as not touching so much that would >> cause things to differ too much as if the build was native, such as >> emulating perl. And 'scratchbox done right' ;) > > I think that needs a bit of debate.
Gladly ;) > >> To avoid the trap of the static toolset, it was chosen to take the >> existing x86-built binaries in OBS, build-dep on them and simply >> (through OBS methods) export them from the X86 build to the ARM build >> scheduler, replacing the ARM binaries in place with X86 binaries, >> which had been rewritten to use a different rpath [4, also documents >> cross toolchain method]. > > This is what I really don't like. Repository or rootstrap shouldn't > be "a random" mix of packages for different architectures. Well, it's not really a random mix - but in truth, isn't it exactly what SB1/2 does as well? Mixing binaries. Keep in mind that the -x86 packages aren't the full packages of their non-x86 counterparts. carsten@ideapad:~/Downloads/f/ii$ rpm2cpio ../../file-x86-arm-5.04-1.1.Mer.armv7l.rpm | cpio -idv ./emul/ia32-linux/usr ./emul/ia32-linux/usr/bin ./emul/ia32-linux/usr/bin/file ./emul/ia32-linux/usr/share ./emul/ia32-linux/usr/share/applybinary ./emul/ia32-linux/usr/share/applybinary/file-x86 This is the 'file' binary - exactly same as in the "file" package's x86 counterpart rpath'd to be using /emul/ia32-linux instead. They are -NOT- ./configure --prefix'ed to another path > >> This meant that we were always sure, that the >> accelerated X86 binary on ARM side would match the original ARM >> binary's source version. > > This approach is no different from what is recommended for SB2 > currently (on the mailing list, it's documentation is quite lacking). > > Except that: > - you mix in the same place x86 & ARM packages Not exactly true, see above > - because of above, you need to rename acceleration packages No, they're actually more like overlays - we actually install both ARM package and package-x86 > - your x86 binaries are in different path so that they don't > conflict with target ones That's partly true - we have both ARM and accelerated binaries in the resulting chroot, but as said before, they overlay. Let me drag out the %post of such a resulting package: carsten@ideapad:~/Downloads/f/ii$ rpm -q --scripts -p ../../file-x86-arm-5.04-1.1.Mer.armv7l.rpm warning: ../../file-x86-arm-5.04-1.1.Mer.armv7l.rpm: Header V3 DSA/SHA1 Signature, key ID 0a94df2f: NOKEY postinstall scriptlet (using /bin/sh): /sbin/ldconfig mv /usr/bin/file /usr/bin/file.orig-arm ; ln -s /emul/ia32-linux/usr/bin/file /usr/bin/file preuninstall scriptlet (using /bin/sh): rm -f /usr/bin/file ; mv /usr/bin/file.orig-arm /usr/bin/file As you can see, it basically takes the ia32 binary and dumps it in place of the ARM binary. > -> you can leak wrong paths to generated scripts like SB1 does I think this one is a bit misunderstood, we don't actually use PATH tricks or similar, we replace the ARM binaries with their X86 counterparts, compiled to exactly same > - your control is on the package level, you cannot have more > fine-grained control. That for example prevents accelerating > more packages We're already replacing binaries on fine-grained level of filesystem, I'd say (see above) > - you cannot enforce/detect issues when acceleration packages cross > the lines they shouldn't[1]. > ? > > [1] This is what newer SB2 versions have been paying some attention. > Latest added for example some support for detecting/controlling > whether builds access internet as some packages like to "call home" > when they're built... You can do that with KVM if you really wanted - most people just opt to block network access instead of the worker > If latest SB2 gets proper RPM support, would there be interest to > try that with OBS? Of course, we're trying to avoid NIH and if there's better technologies that is of course of interest - getting them evaluated in an open manner. > > >> Some of us in "old" Mer explored SB2 as an approach back in 2008 but >> didn't find it working properly enough at that time - it may have >> stablized a lot since. > > It has. And its default rules don't try to accelerate quite as > much as first versions did as that caused some issues. > > > How up to date the last two pages are e.g. in regards to what binaries > are accelerated? They mention armv5 toolchains... Same method for toolchains is still in use, but has grown since that documentation was written. We now also accelerate RPM installs and RPM building - the most slow part of builds is the chroot setup. http://localhost:2080/project/packages?project=Core%3Aarmv7l -- find packages with "-x86" and it gives you a good idea what's accelerated - you'd have to look into binaries_to_prepare in each package to figure out what binaries they specifically accelerate. BR Carsten Munk _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
