kernel-packages team mailing list archive

[Colin Watson <cjwatson@xxxxxxxxxxxxx>]

Public bug reported:

We're working on bringing up new arm64 builder infrastructure in
Launchpad scalingstack to replace the current bare-metal builders, and
the current plan is that they should be able to cover armhf as well.
Ideally, we would be able to do this using the same guest images:
scalingstack builders are reset at the end of the previous build so that
latency for new builds is lower when the build farm isn't at 100% use,
which means that we don't in general know which architecture a given
builder is going to need to build next, so we can get better density out
of our hardware by having the same guest images be able to handle more
than one architecture.

Things mostly work just by chrooting into an armhf chroot under linux32.
However, this causes "uname -m" to print "armv8l", while our current
value on our armhf builders is "armv7l".  I'd initially thought that
this would be tolerable, but my understanding from Adam Conrad is that
the breakage from poorly-written build scripts that misdetect the
architecture as a result is quite widespread.  So, we would like to have
a personality value available that would cause "uname -m" to print
"armv7l".

This doesn't look completely trivial, because newuname() basically just
has compat and non-compat mode for architectures based on whether the
personality is PER_LINUX32 or not, and doesn't currently seem to have
extension points beyond that.  I'm hoping this is fixable.  If not, we
need to know with as much lead time as possible so that we can bring up
separate armhf guests, since that's going to be a fair amount of work
for us to arrange.

** Affects: linux (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: bot-stop-nagging

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1520627

Title:
  New personality for more accurate armv7l emulation on arm64

Status in linux package in Ubuntu:
  New

Bug description:
  We're working on bringing up new arm64 builder infrastructure in
  Launchpad scalingstack to replace the current bare-metal builders, and
  the current plan is that they should be able to cover armhf as well.
  Ideally, we would be able to do this using the same guest images:
  scalingstack builders are reset at the end of the previous build so
  that latency for new builds is lower when the build farm isn't at 100%
  use, which means that we don't in general know which architecture a
  given builder is going to need to build next, so we can get better
  density out of our hardware by having the same guest images be able to
  handle more than one architecture.

  Things mostly work just by chrooting into an armhf chroot under
  linux32.  However, this causes "uname -m" to print "armv8l", while our
  current value on our armhf builders is "armv7l".  I'd initially
  thought that this would be tolerable, but my understanding from Adam
  Conrad is that the breakage from poorly-written build scripts that
  misdetect the architecture as a result is quite widespread.  So, we
  would like to have a personality value available that would cause
  "uname -m" to print "armv7l".

  This doesn't look completely trivial, because newuname() basically
  just has compat and non-compat mode for architectures based on whether
  the personality is PER_LINUX32 or not, and doesn't currently seem to
  have extension points beyond that.  I'm hoping this is fixable.  If
  not, we need to know with as much lead time as possible so that we can
  bring up separate armhf guests, since that's going to be a fair amount
  of work for us to arrange.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1520627/+subscriptions