I already have emulator-x86-kk running locally with a patched kernel, so it's a simple matter of documenting and pushing to GitHub, once any x86-specific breakages (e.g., bug 997409) are dealt with. emulator-x86-kk is of particular interest due to ongoing plans to use it as the primary B2G test running platform for Buildbot/TBPL; see bug 753928 comment #15.

We're currently using the upstream version of prebuilts/qemu-kernel on emulator-x86-kk. Ours is versioned by b2g versions (master, v1.4, etc.); theirs is versioned with Android versions (kitkat, jb, etc.). And they changed the default from 2.6 to 3.4 between JB and KK. So we could add a kitkat branch to our fork... and then a kitkat-1.5, kitkat-1.6, etc. as new releases come out, paralleling the existing versions, or more likely forget to do that, and it would probably be a mess in any case. Or we could change run-emulator.sh to determine the desired kernel version from $DEVICE_NAME and update the 3.4 kernels to the latest upstream version before patching.

This lets us use KK emulators with a prebuilts/qemu-kernel where 2.6 is the default, as well as ICS/JB emulators when 3.4 is the default, without affecting existing usage.

Comment on attachment 8415742 [details] Link to Github pull-request: https://github.com/mozilla-b2g/B2G/pull/344 Hi, I think there is some misunderstanding here. In emulator{,-x86}-kk variants, we have following directory layout in prebuilts/qemu-kernel: . ├── arm │   ├── 2.6 │   │   ├── kernel-qemu │   │   ├── kernel-qemu-armv7 │   │   ├── vmlinux-qemu │   │   └── vmlinux-qemu-armv7 │   ├── kernel-qemu │   ├── kernel-qemu-armv7 │   ├── LINUX_KERNEL_COPYING │   ├── README │   ├── rebuild.sh │   ├── vmlinux-qemu │   └── vmlinux-qemu-armv7 └── x86 ├── 2.6 │   ├── kernel-qemu │   └── vmlinux-qemu ├── kernel-qemu ├── kernel-vbox ├── LINUX_KERNEL_COPYING ├── pc-bios │   ├── Android.mk │   ├── bios.bin │   └── vgabios-cirrus.bin ├── README ├── vmlinux-qemu └── vmlinux-vbox But for emulator{,-x86}{,-jb} we have: . ├── arm │   ├── 3.4 │   │   ├── kernel-qemu-armv7 │   │   └── vmlinux-qemu-armv7 │   ├── kernel-qemu │   ├── kernel-qemu-armv7 │   ├── LINUX_KERNEL_COPYING │   ├── README │   ├── rebuild.sh │   ├── vmlinux-qemu │   └── vmlinux-qemu-armv7 └── x86 ├── 3.4 │   ├── kernel-qemu │   └── vmlinux-qemu ├── kernel-qemu ├── kernel-vbox ├── LINUX_KERNEL_COPYING ├── pc-bios │   ├── Android.mk │   ├── bios.bin │   └── vgabios-cirrus.bin ├── README ├── vmlinux-qemu └── vmlinux-vbox We're __always__ using kernel binaries right under prebuilts/qemu-kernel/${TARGET_ARCH} in __all__ emulator variants. We don't need this pull request and everything just works fine.

(In reply to Vicamo Yang [:vicamo][:vyang] from comment #3) > Hi, I think there is some misunderstanding here. In emulator{,-x86}-kk > variants, we have following directory layout in prebuilts/qemu-kernel: > . > ├── arm > │   ├── 2.6 [...] Because we're using tag "android-4.4.2_r1" from CodeAurora's repo. > But for emulator{,-x86}{,-jb} we have: > . > ├── arm > │   ├── 3.4 [...] Because we're using our own repo, which we forked before the version change. So if we want to make changes to the emulator-kk kernel, we'd have to make a separate fork instead of being able to use the same repo for all of the emulators.

I talked with mwu on IRC about this — the Right Way to do this is to create branches in our platform_prebuilts_qemu-kernel named b2g-N.M.P_rQ based on the corresponding android-N.M.P_rQ tag from upstream (for whatever values of N,M,P,Q) and commit to those. I've created the b2g-4.4.2_r1 branch in (and also pushed the android_4.4.2_r1 tag to) our repo, to get this started.

This pull request updates the b2g-goldfish-3.4 branch of mozilla-b2g/kernel_goldfish to match the source revision (6dff53c) mentioned in the android-4.4.2_r1 tag of prebuilts/qemu-kernel, which is what we're currently using for emulator-kk, which is the only goldfish where we currently use a 3.4 kernel.

Comment on attachment 8419655 [details] GitHub PR to update emulator kernel source 3.4 branch to android-4.4.2_r1 Thank you :) https://github.com/mozilla-b2g/kernel_goldfish/commit/6dff53caa619cef08ef4cfae48d3f186b0568a0f

(In reply to Vicamo Yang [:vicamo][:vyang] from comment #8) > Created attachment 8419896 [details] > Github PR for b2g-manifest, switch qemu-kernel to b2g_4.4.2_r1 branch Had been mirrored to gmo: http://git.mozilla.org/?p=b2g/platform_prebuilts_qemu-kernel.git;a=shortlog;h=refs/heads/b2g-4.4.2_r1

I've built emulator-kk and emulator-x86-kk, checked out the binaries from attachment 8422090 [details], successfully booted B2G with them, and verified that seccomp-bpf was in use.

Comment on attachment 8422088 [details] Link to Github pull-request: https://github.com/mozilla-b2g/kernel_goldfish/pull/9 I think I'm not the best person to review this. All I can do here is to run some test cases with proposed kernel images and see if something goes obviously wrong. I'll just rubber-stamp here if you can't find somebody more appropriate. I found you've also updated MIPS defconfig. Could you also attach updated MIPS kernel images? I think I can help verify them with AOSP emulator. Thank you.

(In reply to Vicamo Yang [:vicamo][:vyang] from comment #14) > I found you've also updated MIPS defconfig. Could you also attach updated > MIPS kernel images? I think I can help verify them with AOSP emulator. Latest 3.4 MIPS kernel images are also built from 6dff53c, so the update here won't include any new change but seccomp-bpf. Just use --arch=mips in `build-kernel.sh` arguments. :)

(In reply to Vicamo Yang [:vicamo][:vyang] from comment #14) > Comment on attachment 8422088 [details] > Link to Github pull-request: > https://github.com/mozilla-b2g/kernel_goldfish/pull/9 > > I think I'm not the best person to review this. All I can do here is to run > some test cases with proposed kernel images and see if something goes > obviously wrong. I'll just rubber-stamp here if you can't find somebody > more appropriate. Everything in the PR except the last commit to change the config files is cherry-picked with no changes from the ChromeOS 3.4 fork, so those shouldn't need any further code review at this point. > I found you've also updated MIPS defconfig. Could you also attach updated > MIPS kernel images? I think I can help verify them with AOSP emulator. That was a mistake; MIPS doesn't have seccomp-bpf support (HAVE_ARCH_SECCOMP_FILTER), so that breaks the MIPS goldfish kernel build. I'll revert the part of the patch and update the PR.

Comment on attachment 8422088 [details] Link to Github pull-request: https://github.com/mozilla-b2g/kernel_goldfish/pull/9 I re-pushed, so re-r?'ing. Also, getting more review.

ARM emulator is working and marionette/xpcshell test cases passed. Verifying x86 emulator.

Comment on attachment 8422090 [details] Link to Github pull-request: https://github.com/mozilla-b2g/platform_prebuilts_qemu-kernel/pull/6 I can see seccomp-bpf in action in both ARM & x86 emulators from b2g-ps. Thank you!

I can help merge the two pull requests if gdestuynder has no further comments.

Comment on attachment 8422088 [details] Link to Github pull-request: https://github.com/mozilla-b2g/kernel_goldfish/pull/9 haa, binary reviews ;) I checked the cherrypicked list - looking good - go ahead

https://github.com/mozilla-b2g/kernel_goldfish/commit/53b37a69fde441a92b77357104829d24a01260ee https://github.com/mozilla-b2g/platform_prebuilts_qemu-kernel/commit/e4ab05cf394cc990d66c81ae4a04cce3be77ab26