qemu-system: new package
PATCH 1/3 qemu-system: new package
--- package/Config.in.host | 1 + package/qemu-system/Config.in.host | 30 ++++++++++++++++++ package/qemu-system/qemu-system.mk | 64 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 95 insertions(+) create mode 100644 package/qemu-system/Config.in.host create mode 100644 package/qemu-system/qemu-system.mk
package/Config.in.host +1 -0
@@ -13,6 +13,7 @@ source "package/mtools/Config.in.host" source "package/omap-u-boot-utils/Config.in.host" source "package/openocd/Config.in.host" source "package/parted/Config.in.host" +source "package/qemu-system/Config.in.host" source "package/sam-ba/Config.in.host" source "package/squashfs/Config.in.host" source "package/sunxi-tools/Config.in.host"
package/qemu-system/Config.in.host new file +30 -0
@@ -0,0 +1,30 @@ +config BR2_PACKAGE_HOST_QEMU_SYSTEM + bool "host qemu-system" + # Supported system target architectures + depends on BR2_arm || BR2_i386 || BR2_microblaze || BR2_mips \ + || BR2_mips64 || BR2_mips64el || BR2_mipsel || BR2_powerpc \ + || BR2_sh4 || BR2_sh4eb || BR2_sparc || BR2_x86_64 + help + QEMU is a generic and open source machine emulator and virtualizer. + + This option builds a system emulator for your selected architecture. + + http://www.qemu.org + +if BR2_PACKAGE_HOST_QEMU_SYSTEM + +config BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION + string "qemu version" + default "2.0.0" + help + QEMU version to use. + Sometimes the latest version is broken for some specific + architecture or target machine. + +config BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS + string "qemu-system command arguments" + help + Arguments to be used for your target host-qemu-system to run + via "make qemu-system-run". + +endif
package/qemu-system/qemu-system.mk new file +64 -0
64 lines not on this page · raw message
Signature · 1 line
1.8.3.2
PATCH 2/3 configs/qemu: update for host-qemu-system
Add the invocation parameter for use with host-qemu-system. Narrow down the Qemu version like it's done for kernel headers since we can't guarantee that a host-qemu-system version bump won't break the configs.
--- configs/qemu_arm_nuri_defconfig | 5 +++++ configs/qemu_arm_versatile_defconfig | 5 +++++ configs/qemu_arm_vexpress_defconfig | 5 +++++ configs/qemu_microblazebe_mmu_defconfig | 5 +++++ configs/qemu_microblazeel_mmu_defconfig | 5 +++++ configs/qemu_mips64_malta_defconfig | 5 +++++ configs/qemu_mips64el_malta_defconfig | 5 +++++ configs/qemu_mips_malta_defconfig | 5 +++++ configs/qemu_mipsel_malta_defconfig | 5 +++++ configs/qemu_ppc_g3beige_defconfig | 5 +++++ configs/qemu_ppc_mpc8544ds_defconfig | 5 +++++ configs/qemu_ppc_virtex_ml507_defconfig | 5 +++++ configs/qemu_sh4_r2d_defconfig | 5 +++++ configs/qemu_sparc_ss10_defconfig | 5 +++++ configs/qemu_x86_64_defconfig | 5 +++++ configs/qemu_x86_defconfig | 5 +++++ 16 files changed, 80 insertions(+)
configs/qemu_arm_nuri_defconfig +5 -0
@@ -25,3 +25,8 @@ BR2_LINUX_KERNEL_CUSTOM_VERSION=y BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.10.32" BR2_LINUX_KERNEL_DEFCONFIG="exynos4" BR2_LINUX_KERNEL_ZIMAGE=y + +# Qemu-system +BR2_PACKAGE_HOST_QEMU_SYSTEM=y +BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0" +BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M nuri -kernel output/images/zImage -append 'console=ttySAC1,115200' -smp 2 -serial null -serial stdio -display curses"
configs/qemu_arm_versatile_defconfig +5 -0
@@ -22,3 +22,8 @@ BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5" BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/arm-versatile/linux-3.13.config" BR2_LINUX_KERNEL_ZIMAGE=y + +# Qemu-system +BR2_PACKAGE_HOST_QEMU_SYSTEM=y +BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0" +BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M versatilepb -kernel output/images/zImage -drive file=output/images/rootfs.ext2,if=scsi -append 'root=/dev/sda console=ttyAMA0,115200' -serial stdio -net nic,model=smc91c111 -net user -display none"
configs/qemu_arm_vexpress_defconfig +5 -0
@@ -24,3 +24,8 @@ BR2_LINUX_KERNEL_CUSTOM_VERSION=y BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5" BR2_LINUX_KERNEL_DEFCONFIG="vexpress" BR2_LINUX_KERNEL_ZIMAGE=y + +# Qemu +BR2_PACKAGE_HOST_QEMU_SYSTEM=y +BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0" +BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M vexpress-a9 -kernel output/images/zImage -drive file=output/images/rootfs.ext2,if=sd -append 'console=ttyAMA0,115200 root=/dev/mmcblk0' -serial stdio -net nic,model=lan9118 -net user -display none"
configs/qemu_microblazebe_mmu_defconfig +5 -0
@@ -17,3 +17,8 @@ BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/microblazebe-mmu/linux-3.14.config" BR2_LINUX_KERNEL_LINUX_BIN=y BR2_LINUX_KERNEL_PATCH="board/qemu/microblazebe-mmu/xilinx-xemaclite.patch" + +# Qemu +BR2_PACKAGE_HOST_QEMU_SYSTEM=y +BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0" +BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M petalogix-s3adsp1800 -kernel output/images/linux.bin -serial stdio -display none"
configs/qemu_microblazeel_mmu_defconfig +5 -0
@@ -17,3 +17,8 @@ BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/microblazeel-mmu/linux-3.14.config" BR2_LINUX_KERNEL_LINUX_BIN=y BR2_LINUX_KERNEL_PATCH="board/qemu/microblazeel-mmu/xilinx-xemaclite.patch" + +# Qemu +BR2_PACKAGE_HOST_QEMU_SYSTEM=y +BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0" +BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M petalogix-s3adsp1800 -kernel output/images/linux.bin -serial stdio -display none"
configs/qemu_mips64_malta_defconfig +5 -0
@@ -22,3 +22,8 @@ BR2_LINUX_KERNEL_VMLINUX=y # Serial port config BR2_TARGET_GENERIC_GETTY=y BR2_TARGET_GENERIC_GETTY_PORT="ttyS0" + +# Qemu +BR2_PACKAGE_HOST_QEMU_SYSTEM=y +BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0" +BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M malta -kernel output/images/vmlinux -serial stdio -hda output/images/rootfs.ext2 -append 'root=/dev/hda' -display none"
configs/qemu_mips64el_malta_defconfig +5 -0
@@ -25,3 +25,8 @@ BR2_LINUX_KERNEL_VMLINUX=y # Serial port config BR2_TARGET_GENERIC_GETTY=y BR2_TARGET_GENERIC_GETTY_PORT="ttyS0" + +# Qemu +BR2_PACKAGE_HOST_QEMU_SYSTEM=y +BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0" +BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M malta -kernel output/images/vmlinux -serial stdio -hda output/images/rootfs.ext2 -append 'root=/dev/hda' -display none"
configs/qemu_mips_malta_defconfig +5 -0
@@ -22,3 +22,8 @@ BR2_LINUX_KERNEL_VMLINUX=y # Serial port config BR2_TARGET_GENERIC_GETTY=y BR2_TARGET_GENERIC_GETTY_PORT="ttyS0" + +# Qemu +BR2_PACKAGE_HOST_QEMU_SYSTEM=y +BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0" +BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M malta -kernel output/images/vmlinux -serial stdio -hda output/images/rootfs.ext2 -append 'root=/dev/hda' -net nic,model=pcnet -net user -display none"
configs/qemu_mipsel_malta_defconfig +5 -0
@@ -22,3 +22,8 @@ BR2_LINUX_KERNEL_VMLINUX=y # Serial port config BR2_TARGET_GENERIC_GETTY=y BR2_TARGET_GENERIC_GETTY_PORT="ttyS0" + +# Qemu +BR2_PACKAGE_HOST_QEMU_SYSTEM=y +BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0" +BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M malta -kernel output/images/vmlinux -serial stdio -hda output/images/rootfs.ext2 -append 'root=/dev/hda' -net nic,model=pcnet -net user -display none"
configs/qemu_ppc_g3beige_defconfig +5 -0
@@ -22,3 +22,8 @@ BR2_LINUX_KERNEL_VMLINUX=y # Serial port config BR2_TARGET_GENERIC_GETTY=y BR2_TARGET_GENERIC_GETTY_PORT="ttyS0" + +# Qemu +BR2_PACKAGE_HOST_QEMU_SYSTEM=y +BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0" +BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M g3beige -kernel output/images/vmlinux -hda output/images/rootfs.ext2 -append 'console=ttyS0 root=/dev/hda' -serial stdio -net nic,model=rtl8139 -net user -display none"
configs/qemu_ppc_mpc8544ds_defconfig +5 -0
@@ -21,3 +21,8 @@ BR2_LINUX_KERNEL_VMLINUX=y # Serial port config BR2_TARGET_GENERIC_GETTY=y BR2_TARGET_GENERIC_GETTY_PORT="ttyS0" + +# Qemu +BR2_PACKAGE_HOST_QEMU_SYSTEM=y +BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0" +BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M mpc8544ds -kernel output/images/vmlinux -serial stdio -net nic,model=e1000 -net user -display none"
configs/qemu_ppc_virtex_ml507_defconfig +5 -0
@@ -22,3 +22,8 @@ BR2_LINUX_KERNEL_DEFCONFIG="44x/virtex5" BR2_LINUX_KERNEL_VMLINUX=y BR2_LINUX_KERNEL_DTS_SUPPORT=y BR2_LINUX_KERNEL_INTREE_DTS_NAME="virtex440-ml507" + +# Qemu +BR2_PACKAGE_HOST_QEMU_SYSTEM=y +BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0" +BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M virtex-ml507 -kernel output/images/vmlinux -m 256 -append 'console=ttyS0' -display none -nographic -dtb output/images/virtex440-ml507.dtb"
configs/qemu_sh4_r2d_defconfig +5 -0
@@ -26,3 +26,8 @@ BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.2.55" BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/sh4-r2d/linux-3.2.config" BR2_LINUX_KERNEL_ZIMAGE=y + +# Qemu +BR2_PACKAGE_HOST_QEMU_SYSTEM=y +BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0" +BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M r2d -kernel output/images/zImage -drive file=output/images/rootfs.ext2,if=ide -append 'root=/dev/sda console=ttySC1,115200 noiotrap' -serial null -serial stdio -net nic,model=rtl8139 -net user -display none"
configs/qemu_sparc_ss10_defconfig +5 -0
@@ -17,3 +17,8 @@ BR2_LINUX_KERNEL_CUSTOM_VERSION=y BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.12.5" BR2_LINUX_KERNEL_DEFCONFIG="sparc32" BR2_LINUX_KERNEL_ZIMAGE=y + +# Qemu +BR2_PACKAGE_HOST_QEMU_SYSTEM=y +BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0" +BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M SS-10 -kernel output/images/zImage -drive file=output/images/rootfs.ext2 -append 'root=/dev/sda console=ttyS0,115200' -serial stdio -net nic,model=lance -net user -display none"
configs/qemu_x86_64_defconfig +5 -0
@@ -20,3 +20,8 @@ BR2_LINUX_KERNEL_CUSTOM_VERSION=y BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5" BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/x86_64/linux-3.13.config" + +# Qemu +BR2_PACKAGE_HOST_QEMU_SYSTEM=y +BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0" +BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M pc -kernel output/images/bzImage -drive file=output/images/rootfs.ext2,if=ide -append 'root=/dev/sda' -net nic,model=rtl8139 -net user -display curses"
configs/qemu_x86_defconfig +5 -0
@@ -21,3 +21,8 @@ BR2_LINUX_KERNEL_CUSTOM_VERSION=y BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5" BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/x86/linux-3.13.config" + +# Qemu +BR2_PACKAGE_HOST_QEMU_SYSTEM=y +BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION="2.0.0" +BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS="-M pc -kernel output/images/bzImage -drive file=output/images/rootfs.ext2,if=ide -append 'root=/dev/sda' -net nic,model=rtl8139 -net user -display curses"
Signature · 1 line
1.8.3.2
PATCH 3/3 configs/qemu: bump relevant kernel/header versions
In reply to Gustavo Zacarias---
board/qemu/arm-nuri/readme.txt | 2 +-
.../arm-versatile/{linux-3.13.config => linux-3.14.config} | 0
board/qemu/arm-versatile/readme.txt | 2 +-
board/qemu/arm-vexpress/readme.txt | 2 +-
board/qemu/microblazebe-mmu/readme.txt | 2 +-
board/qemu/microblazeel-mmu/readme.txt | 2 +-
board/qemu/mips-malta/{linux-3.13.config => linux-3.14.config} | 0
board/qemu/mips-malta/readme.txt | 2 +-
.../qemu/mips64-malta/{linux-3.13.config => linux-3.14.config} | 0
board/qemu/mips64-malta/readme.txt | 2 +-
.../mips64el-malta/{linux-3.13.config => linux-3.14.config} | 0
board/qemu/mips64el-malta/readme.txt | 2 +-
.../qemu/mipsel-malta/{linux-3.13.config => linux-3.14.config} | 0
board/qemu/mipsel-malta/readme.txt | 2 +-
.../powerpc-g3beige/{linux-3.13.config => linux-3.14.config} | 0
board/qemu/powerpc-g3beige/readme.txt | 2 +-
board/qemu/powerpc-mpc8544ds/readme.txt | 2 +-
board/qemu/powerpc-virtex-ml507/readme.txt | 2 +-
board/qemu/sh4-r2d/readme.txt | 2 +-
board/qemu/sparc-ss10/readme.txt | 2 +-
board/qemu/x86/{linux-3.13.config => linux-3.14.config} | 0
board/qemu/x86/readme.txt | 2 +-
board/qemu/x86_64/{linux-3.13.config => linux-3.14.config} | 0
board/qemu/x86_64/readme.txt | 2 +-
configs/qemu_arm_nuri_defconfig | 4 ++--
configs/qemu_arm_versatile_defconfig | 10 +++++-----
configs/qemu_arm_vexpress_defconfig | 8 ++++----
configs/qemu_mips64_malta_defconfig | 10 +++++-----
configs/qemu_mips64el_malta_defconfig | 10 +++++-----
configs/qemu_mips_malta_defconfig | 10 +++++-----
configs/qemu_mipsel_malta_defconfig | 10 +++++-----
configs/qemu_ppc_g3beige_defconfig | 10 +++++-----
configs/qemu_ppc_mpc8544ds_defconfig | 8 ++++----
configs/qemu_ppc_virtex_ml507_defconfig | 8 ++++----
configs/qemu_sh4_r2d_defconfig | 4 ++--
configs/qemu_sparc_ss10_defconfig | 8 ++++----
configs/qemu_x86_64_defconfig | 10 +++++-----
configs/qemu_x86_defconfig | 10 +++++-----
38 files changed, 76 insertions(+), 76 deletions(-)
rename board/qemu/arm-versatile/{linux-3.13.config => linux-3.14.config} (100%)
rename board/qemu/mips-malta/{linux-3.13.config => linux-3.14.config} (100%)
rename board/qemu/mips64-malta/{linux-3.13.config => linux-3.14.config} (100%)
rename board/qemu/mips64el-malta/{linux-3.13.config => linux-3.14.config} (100%)
rename board/qemu/mipsel-malta/{linux-3.13.config => linux-3.14.config} (100%)
rename board/qemu/powerpc-g3beige/{linux-3.13.config => linux-3.14.config} (100%)
rename board/qemu/x86/{linux-3.13.config => linux-3.14.config} (100%)
rename board/qemu/x86_64/{linux-3.13.config => linux-3.14.config} (100%)board/qemu/arm-nuri/readme.txt +1 -1
@@ -7,4 +7,4 @@ graphical window is the framebuffer. Startup time is slow because of the SMP CPU emulation so be patient. -Tested with QEMU 1.7.0 +Tested with QEMU 2.0.0
board/qemu/arm-versatile/linux-3.14.config renamed from board/qemu/arm-versatile/linux-3.13.config +0 -0
board/qemu/arm-versatile/readme.txt +1 -1
@@ -5,4 +5,4 @@ Run the emulation with: The login prompt will appear in the terminal that started Qemu. The graphical window is the framebuffer. -Tested with QEMU 1.7.0 +Tested with QEMU 2.0.0
board/qemu/arm-vexpress/readme.txt +1 -1
@@ -5,4 +5,4 @@ Run the emulation with: The login prompt will appear in the terminal that started Qemu. The graphical window is the framebuffer. -Tested with QEMU 1.7.0 +Tested with QEMU 2.0.0
board/qemu/microblazebe-mmu/readme.txt +1 -1
@@ -4,4 +4,4 @@ Run the emulation with: The login prompt will appear in the terminal that started Qemu. -Tested with QEMU 1.7.0 +Tested with QEMU 2.0.0
board/qemu/microblazeel-mmu/readme.txt +1 -1
@@ -4,4 +4,4 @@ Run the emulation with: The login prompt will appear in the terminal that started Qemu. -Tested with QEMU 1.7.0 +Tested with QEMU 2.0.0
board/qemu/mips-malta/linux-3.14.config renamed from board/qemu/mips-malta/linux-3.13.config +0 -0
board/qemu/mips-malta/readme.txt +1 -1
@@ -6,4 +6,4 @@ The login prompt will appear in the terminal that started Qemu. The graphical window is the framebuffer. No keyboard support has been enabled. -Tested with QEMU 1.7.0 +Tested with QEMU 2.0.0
board/qemu/mips64-malta/linux-3.14.config renamed from board/qemu/mips64-malta/linux-3.13.config +0 -0
board/qemu/mips64-malta/readme.txt +1 -1
@@ -5,4 +5,4 @@ Run the emulation with: The login prompt will appear in the terminal that started Qemu. The graphical window is the framebuffer. -Tested with QEMU 1.7.0 +Tested with QEMU 2.0.0
board/qemu/mips64el-malta/linux-3.14.config renamed from board/qemu/mips64el-malta/linux-3.13.config +0 -0
board/qemu/mips64el-malta/readme.txt +1 -1
@@ -5,4 +5,4 @@ Run the emulation with: The login prompt will appear in the terminal that started Qemu. The graphical window is the framebuffer. -Tested with QEMU 1.7.0 +Tested with QEMU 2.0.0
board/qemu/mipsel-malta/linux-3.14.config renamed from board/qemu/mipsel-malta/linux-3.13.config +0 -0
board/qemu/mipsel-malta/readme.txt +1 -1
@@ -6,4 +6,4 @@ The login prompt will appear in the terminal that started Qemu. The graphical window is the framebuffer. No keyboard support has been enabled. -Tested with QEMU 1.7.0 +Tested with QEMU 2.0.0
board/qemu/powerpc-g3beige/linux-3.14.config renamed from board/qemu/powerpc-g3beige/linux-3.13.config +0 -0
board/qemu/powerpc-g3beige/readme.txt +1 -1
@@ -5,4 +5,4 @@ Run the emulation with: The login prompt will appear in the terminal that started Qemu. The graphical window is the framebuffer. -Tested with QEMU 1.7.0 +Tested with QEMU 2.0.0
board/qemu/powerpc-mpc8544ds/readme.txt +1 -1
@@ -4,4 +4,4 @@ Run the emulation with: The login prompt will appear in the terminal that started Qemu. -Tested with QEMU 1.7.0 +Tested with QEMU 2.0.0
board/qemu/powerpc-virtex-ml507/readme.txt +1 -1
@@ -5,4 +5,4 @@ Run the emulation with: The login prompt will appear in the terminal that started Qemu. -Tested with QEMU 1.7.0 +Tested with QEMU 2.0.0
board/qemu/sh4-r2d/readme.txt +1 -1
@@ -5,4 +5,4 @@ Run the emulation with: The login prompt will appear in the terminal that started Qemu. The graphical window is the framebuffer. -Tested with QEMU 1.7.0 +Tested with QEMU 2.0.0
board/qemu/sparc-ss10/readme.txt +1 -1
@@ -5,4 +5,4 @@ Run the emulation with: The login prompt will appear in the terminal that started Qemu. The graphical window is the framebuffer. -Tested with QEMU 1.6.1 +Tested with QEMU 2.0.0
board/qemu/x86/linux-3.14.config renamed from board/qemu/x86/linux-3.13.config +0 -0
board/qemu/x86/readme.txt +1 -1
@@ -4,4 +4,4 @@ Run the emulation with: The login prompt will appear in the graphical window. -Tested with QEMU 1.7.0 +Tested with QEMU 2.0.0
board/qemu/x86_64/linux-3.14.config renamed from board/qemu/x86_64/linux-3.13.config +0 -0
board/qemu/x86_64/readme.txt +1 -1
@@ -4,4 +4,4 @@ Run the emulation with: The login prompt will appear in the graphical window. -Tested with QEMU 1.7.0 +Tested with QEMU 2.0.0
configs/qemu_arm_nuri_defconfig +2 -2
@@ -16,13 +16,13 @@ BR2_TARGET_ROOTFS_INITRAMFS=y # Lock to 3.10 headers to avoid breaking with newer kernels # Stuck at 3.10.x because there's no Nuri DTS BR2_KERNEL_HEADERS_VERSION=y -BR2_DEFAULT_KERNEL_VERSION="3.10.32" +BR2_DEFAULT_KERNEL_VERSION="3.10.38" BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_10=y # Kernel BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_VERSION=y -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.10.32" +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.10.38" BR2_LINUX_KERNEL_DEFCONFIG="exynos4" BR2_LINUX_KERNEL_ZIMAGE=y
configs/qemu_arm_versatile_defconfig +5 -5
@@ -10,17 +10,17 @@ BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0" BR2_TARGET_ROOTFS_EXT2=y # BR2_TARGET_ROOTFS_TAR is not set -# Lock to 3.13 headers to avoid breaking with newer kernels +# Lock to 3.14 headers to avoid breaking with newer kernels BR2_KERNEL_HEADERS_VERSION=y -BR2_DEFAULT_KERNEL_VERSION="3.13.5" -BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_13=y +BR2_DEFAULT_KERNEL_VERSION="3.14.2" +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_14=y # Kernel BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_VERSION=y -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5" +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.14.2" BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y -BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/arm-versatile/linux-3.13.config" +BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/arm-versatile/linux-3.14.config" BR2_LINUX_KERNEL_ZIMAGE=y # Qemu-system
configs/qemu_arm_vexpress_defconfig +4 -4
@@ -13,15 +13,15 @@ BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0" BR2_TARGET_ROOTFS_EXT2=y # BR2_TARGET_ROOTFS_TAR is not set -# Lock to 3.13 headers to avoid breaking with newer kernels +# Lock to 3.14 headers to avoid breaking with newer kernels BR2_KERNEL_HEADERS_VERSION=y -BR2_DEFAULT_KERNEL_VERSION="3.13.5" -BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_13=y +BR2_DEFAULT_KERNEL_VERSION="3.14.2" +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_14=y # Kernel BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_VERSION=y -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5" +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.14.2" BR2_LINUX_KERNEL_DEFCONFIG="vexpress" BR2_LINUX_KERNEL_ZIMAGE=y
configs/qemu_mips64_malta_defconfig +5 -5
@@ -6,17 +6,17 @@ BR2_MIPS_NABI64=y BR2_TARGET_ROOTFS_EXT2=y # BR2_TARGET_ROOTFS_TAR is not set -# Lock to 3.13 headers to avoid breaking with newer kernels +# Lock to 3.14 headers to avoid breaking with newer kernels BR2_KERNEL_HEADERS_VERSION=y -BR2_DEFAULT_KERNEL_VERSION="3.13.5" -BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_13=y +BR2_DEFAULT_KERNEL_VERSION="3.14.2" +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_14=y # Kernel BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_VERSION=y -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5" +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.14.2" BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y -BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/mips64-malta/linux-3.13.config" +BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/mips64-malta/linux-3.14.config" BR2_LINUX_KERNEL_VMLINUX=y # Serial port config
configs/qemu_mips64el_malta_defconfig +5 -5
@@ -9,17 +9,17 @@ BR2_TOOLCHAIN_BUILDROOT_EGLIBC=y BR2_TARGET_ROOTFS_EXT2=y # BR2_TARGET_ROOTFS_TAR is not set -# Lock to 3.13 headers to avoid breaking with newer kernels +# Lock to 3.14 headers to avoid breaking with newer kernels BR2_KERNEL_HEADERS_VERSION=y -BR2_DEFAULT_KERNEL_VERSION="3.13.5" -BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_13=y +BR2_DEFAULT_KERNEL_VERSION="3.14.2" +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_14=y # Kernel BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_VERSION=y -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5" +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.14.2" BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y -BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/mips64el-malta/linux-3.13.config" +BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/mips64el-malta/linux-3.14.config" BR2_LINUX_KERNEL_VMLINUX=y # Serial port config
configs/qemu_mips_malta_defconfig +5 -5
@@ -6,17 +6,17 @@ BR2_mips_32r2=y BR2_TARGET_ROOTFS_EXT2=y # BR2_TARGET_ROOTFS_TAR is not set -# Lock to 3.13 headers to avoid breaking with newer kernels +# Lock to 3.14 headers to avoid breaking with newer kernels BR2_KERNEL_HEADERS_VERSION=y -BR2_DEFAULT_KERNEL_VERSION="3.13.5" -BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_13=y +BR2_DEFAULT_KERNEL_VERSION="3.14.2" +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_14=y # Kernel BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_VERSION=y -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5" +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.14.2" BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y -BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/mips-malta/linux-3.13.config" +BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/mips-malta/linux-3.14.config" BR2_LINUX_KERNEL_VMLINUX=y # Serial port config
configs/qemu_mipsel_malta_defconfig +5 -5
@@ -6,17 +6,17 @@ BR2_mips_32r2=y BR2_TARGET_ROOTFS_EXT2=y # BR2_TARGET_ROOTFS_TAR is not set -# Lock to 3.13 headers to avoid breaking with newer kernels +# Lock to 3.14 headers to avoid breaking with newer kernels BR2_KERNEL_HEADERS_VERSION=y -BR2_DEFAULT_KERNEL_VERSION="3.13.5" -BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_13=y +BR2_DEFAULT_KERNEL_VERSION="3.14.2" +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_14=y # Kernel BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_VERSION=y -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5" +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.14.2" BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y -BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/mipsel-malta/linux-3.13.config" +BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/mipsel-malta/linux-3.14.config" BR2_LINUX_KERNEL_VMLINUX=y # Serial port config
configs/qemu_ppc_g3beige_defconfig +5 -5
@@ -6,17 +6,17 @@ BR2_powerpc_750=y BR2_TARGET_ROOTFS_EXT2=y # BR2_TARGET_ROOTFS_TAR is not set -# Lock to 3.13 headers to avoid breaking with newer kernels +# Lock to 3.14 headers to avoid breaking with newer kernels BR2_KERNEL_HEADERS_VERSION=y -BR2_DEFAULT_KERNEL_VERSION="3.13.5" -BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_13=y +BR2_DEFAULT_KERNEL_VERSION="3.14.2" +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_14=y # Kernel BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_VERSION=y -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5" +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.14.2" BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y -BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/powerpc-g3beige/linux-3.13.config" +BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/powerpc-g3beige/linux-3.14.config" BR2_LINUX_KERNEL_VMLINUX=y # Serial port config
configs/qemu_ppc_mpc8544ds_defconfig +4 -4
@@ -6,15 +6,15 @@ BR2_powerpc_8548=y # BR2_TARGET_ROOTFS_TAR is not set BR2_TARGET_ROOTFS_INITRAMFS=y -# Lock to 3.13 headers to avoid breaking with newer kernels +# Lock to 3.14 headers to avoid breaking with newer kernels BR2_KERNEL_HEADERS_VERSION=y -BR2_DEFAULT_KERNEL_VERSION="3.13.5" -BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_13=y +BR2_DEFAULT_KERNEL_VERSION="3.14.2" +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_14=y # Kernel BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_VERSION=y -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5" +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.14.2" BR2_LINUX_KERNEL_DEFCONFIG="mpc85xx" BR2_LINUX_KERNEL_VMLINUX=y
configs/qemu_ppc_virtex_ml507_defconfig +4 -4
@@ -6,10 +6,10 @@ BR2_powerpc_440=y # BR2_TARGET_ROOTFS_TAR is not set BR2_TARGET_ROOTFS_INITRAMFS=y -# Lock to 3.13 headers to avoid breaking with newer kernels +# Lock to 3.14 headers to avoid breaking with newer kernels BR2_KERNEL_HEADERS_VERSION=y -BR2_DEFAULT_KERNEL_VERSION="3.13.5" -BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_13=y +BR2_DEFAULT_KERNEL_VERSION="3.14.2" +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_14=y # Use soft float BR2_SOFT_FLOAT=y
@@ -17,7 +17,7 @@ BR2_SOFT_FLOAT=y # Kernel BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_VERSION=y -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5" +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.14.2" BR2_LINUX_KERNEL_DEFCONFIG="44x/virtex5" BR2_LINUX_KERNEL_VMLINUX=y BR2_LINUX_KERNEL_DTS_SUPPORT=y
configs/qemu_sh4_r2d_defconfig +2 -2
@@ -12,7 +12,7 @@ BR2_TARGET_ROOTFS_EXT2=y # Lock to 3.2 headers to avoid breaking with newer kernels BR2_KERNEL_HEADERS_VERSION=y -BR2_DEFAULT_KERNEL_VERSION="3.2.55" +BR2_DEFAULT_KERNEL_VERSION="3.2.58" BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_2=y # The kernel wants to use the -m4-nofpu option to make sure that it
@@ -22,7 +22,7 @@ BR2_EXTRA_GCC_CONFIG_OPTIONS="--with-multilib-list=m4,m4-nofpu" # Linux kernel BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_VERSION=y -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.2.55" +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.2.58" BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/sh4-r2d/linux-3.2.config" BR2_LINUX_KERNEL_ZIMAGE=y
configs/qemu_sparc_ss10_defconfig +4 -4
@@ -6,15 +6,15 @@ BR2_sparc_v8=y BR2_TARGET_ROOTFS_EXT2=y # BR2_TARGET_ROOTFS_TAR is not set -# Lock to 3.12 headers to avoid breaking with newer kernels +# Lock to 3.14 headers to avoid breaking with newer kernels BR2_KERNEL_HEADERS_VERSION=y -BR2_DEFAULT_KERNEL_VERSION="3.12.5" -BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_12=y +BR2_DEFAULT_KERNEL_VERSION="3.14.2" +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_14=y # Linux kernel BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_VERSION=y -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.12.5" +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.14.2" BR2_LINUX_KERNEL_DEFCONFIG="sparc32" BR2_LINUX_KERNEL_ZIMAGE=y
configs/qemu_x86_64_defconfig +5 -5
@@ -9,17 +9,17 @@ BR2_TARGET_GENERIC_GETTY_PORT="tty1" BR2_TARGET_ROOTFS_EXT2=y # BR2_TARGET_ROOTFS_TAR is not set -# Lock to 3.13 headers to avoid breaking with newer kernels +# Lock to 3.14 headers to avoid breaking with newer kernels BR2_KERNEL_HEADERS_VERSION=y -BR2_DEFAULT_KERNEL_VERSION="3.13.5" -BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_13=y +BR2_DEFAULT_KERNEL_VERSION="3.14.2" +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_14=y # Kernel BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_VERSION=y -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5" +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.14.2" BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y -BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/x86_64/linux-3.13.config" +BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/x86_64/linux-3.14.config" # Qemu BR2_PACKAGE_HOST_QEMU_SYSTEM=y
configs/qemu_x86_defconfig +5 -5
@@ -10,17 +10,17 @@ BR2_TARGET_GENERIC_GETTY_PORT="tty1" BR2_TARGET_ROOTFS_EXT2=y # BR2_TARGET_ROOTFS_TAR is not set -# Lock to 3.13 headers to avoid breaking with newer kernels +# Lock to 3.14 headers to avoid breaking with newer kernels BR2_KERNEL_HEADERS_VERSION=y -BR2_DEFAULT_KERNEL_VERSION="3.13.5" -BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_13=y +BR2_DEFAULT_KERNEL_VERSION="3.14.2" +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_14=y # Kernel BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_VERSION=y -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.13.5" +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.14.2" BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y -BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/x86/linux-3.13.config" +BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/x86/linux-3.14.config" # Qemu BR2_PACKAGE_HOST_QEMU_SYSTEM=y
Signature · 1 line
1.8.3.2
PATCH 1/3 qemu-system: new package
In reply to Gustavo ZacariasDear Gustavo Zacarias,
Quoted 8 lines · Gustavo Zacarias
Signed-off-by Gustavo Zacarias <[email protected]>--- package/Config.in.host | 1 + package/qemu-system/Config.in.host | 30 ++++++++++++++++++ package/qemu-system/qemu-system.mk | 64 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 95 insertions(+) create mode 100644 package/qemu-system/Config.in.host create mode 100644 package/qemu-system/qemu-system.mk
We discussed this patch series during the Buildroot meeting. PATCH 3/3 is Superseded, as you have updated the Qemu defconfigs many time since then.
Regarding PATCH 1/3 and PATCH 2/3, we continue to believe it should be part of the qemu package itself, and not a separate qemu-system. Since I know you are not interested in doing this work, Yann E. Morin has said he was interested in doing this, once his current patch series adding support for qemu-system on the target has been merged.
Consequently, I will mark your patches as 'Changes Requested' in patchwork. Of course, if in the mean time you change your mind and decide to implement host qemu-system as part of the qemu package, we'd be happy to receive your patches! :-)
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/3 qemu-system: new package
Quoted 10 lines · Thomas Petazzoni
We discussed this patch series during the Buildroot meeting. PATCH 3/3 is Superseded, as you have updated the Qemu defconfigs many time since then.
Regarding PATCH 1/3 and PATCH 2/3, we continue to believe it should be part of the qemu package itself, and not a separate qemu-system. Since I know you are not interested in doing this work, Yann E. Morin has said he was interested in doing this, once his current patch series adding support for qemu-system on the target has been merged.
Quoted 4 lines
Consequently, I will mark your patches as 'Changes Requested' in patchwork. Of course, if in the mean time you change your mind and decide to implement host qemu-system as part of the qemu package, we'd be happy to receive your patches! :-)
I don't agree on the reasoning:
You can't use different versions for host and non-host packages in a clean way: that alone and the fact that no single qemu version can cover all of the emulations would make the single package pointless. It's all fine and nice to strive to get qemu fixed but it's an unrealistic objective, new architectures and variants together with old emulations that seldomly are used/tested will continue to make this a moving target.
Time and time again this has proven to be the case so leaving a fixed version for the package will make it pointless, we can just tell people to use some random distro version and get the same result which would render the host package with no sense to be.
And changing the package version for the target because the host version needs some special care plays into the changing results arena. Granted it's not a common use-case to have both, but it's doing it regarless.
You want all emulations to work, not just some depending on weather, wind and pollen count.
So on my side i'm not planning to do anything with this decision. Regards.
PATCH 1/3 qemu-system: new package
Quoted 12 lines · Gustavo Zacarias
Quoted 10 lines · Thomas Petazzoni
We discussed this patch series during the Buildroot meeting. PATCH 3/3 is Superseded, as you have updated the Qemu defconfigs many time since then.
Regarding PATCH 1/3 and PATCH 2/3, we continue to believe it should be part of the qemu package itself, and not a separate qemu-system. Since I know you are not interested in doing this work, Yann E. Morin has said he was interested in doing this, once his current patch series adding support for qemu-system on the target has been merged.
Quoted 8 lines
Quoted 4 lines
Consequently, I will mark your patches as 'Changes Requested' in patchwork. Of course, if in the mean time you change your mind and decide to implement host qemu-system as part of the qemu package, we'd be happy to receive your patches! :-)
I don't agree on the reasoning:
You can't use different versions for host and non-host packages in a clean way:
Can you explain why not?
You cannot use different versions for qemu-user and qemu-system in a clean way
if they're not different packages. But host and target versions don't need to be the same. At least, I see code in pkg-generic.mk to handle that.
And I do think we want to keep qemu-user and qemu-system at the same version,
right? Or does it happen that you need different versions for these as well?
The real question is how to make the version depend on the values inBR2_PACKAGE_QEMU_CUSTOM_TARGETS. But that is not the concern of your patch.
Regards,
Arnout
Quoted 25 lines
that alone and the fact that no single qemu version can cover all of the emulations would make the single package pointless. It's all fine and nice to strive to get qemu fixed but it's an unrealistic objective, new architectures and variants together with old emulations that seldomly are used/tested will continue to make this a moving target.
Time and time again this has proven to be the case so leaving a fixed version for the package will make it pointless, we can just tell people to use some random distro version and get the same result which would render the host package with no sense to be.
And changing the package version for the target because the host version needs some special care plays into the changing results arena. Granted it's not a common use-case to have both, but it's doing it regarless.
You want all emulations to work, not just some depending on weather, wind and pollen count.
So on my side i'm not planning to do anything with this decision. Regards._______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
PATCH 1/3 qemu-system: new package
Quoted 5 lines · Arnout Vandecappelle
Can you explain why not?
You cannot use different versions for qemu-user and qemu-system in a clean way
if they're not different packages. But host and target versions don't need to be the same. At least, I see code in pkg-generic.mk to handle that.
Well, not really, for example try modifying package/e2fsprogs.mk:HOST_E2FSPROGS_VERSION = 1.42.13
And build both, see what happens.
Even try a make source with that.
Quoted 5 lines
And I do think we want to keep qemu-user and qemu-system at the same version,
right? Or does it happen that you need different versions for these as well?The real question is how to make the version depend on the values in
BR2_PACKAGE_QEMU_CUSTOM_TARGETS. But that is not the concern of your patch.
No, that's a wrong assumption.
For example qemu_mpc8544ds_defconfig doesn't work with the latest 2.1.2 qemu, however other qemu ppc sample defconfigs do (in fact no 2.1.x version).
And the qemu config should dictate what's the best version for each - not necessarily the latest, you can't make host-qemu-user depend on that since it's a platform decision, not an arch one.
If you want to stick with "the one that works for everything" you potentially miss the opportunity for new arch and/or platform support. So even if target != host version is fixed/possible you'll still clash on host-qemu (user) vs. host-qemu (system) versions since you might want to do the perl module dance (original purpose of host-qemu) vs. platform emulation.
It's nice to keep everything in one package, but it's not feasible to do so in a coherent way for this case in particular.
If you can't get the leash out of the qemu version there's no point in building so for the emulation, sometimes you'll ship every single qemu config working, sometimes you wont - and that's my quarrel, everyone is perfect-this perfect-that but all of the sudden this would be acceptable? Like i said it would be the same as $RANDOM distro qemu. Regards.
PATCH 1/3 qemu-system: new package
Quoted 8 lines · Gustavo Zacarias
Quoted 5 lines · Arnout Vandecappelle
Can you explain why not?
You cannot use different versions for qemu-user and qemu-system in a clean way
if they're not different packages. But host and target versions don't need to be the same. At least, I see code in pkg-generic.mk to handle that.
Quoted 5 lines
Well, not really, for example try modifying
package/e2fsprogs.mk:HOST_E2FSPROGS_VERSION= 1.42.13And build both, see what happens.
Even try a make source with that.
Yeah, OK, you have to set the HOST_FOO_SOURCE explicitly as well due to a
little shortcoming in the infrastructure, but I don't think that should be a showstopper.
Quoted 11 lines
Quoted 6 lines
And I do think we want to keep qemu-user and qemu-system at the same version,
right? Or does it happen that you need different versions for these as well?The real question is how to make the version depend on the values in
BR2_PACKAGE_QEMU_CUSTOM_TARGETS. But that is not the concern of your patch.No, that's a wrong assumption.
For exampleqemu_mpc8544ds_defconfigdoesn't work with the latest 2.1.2 qemu, however other qemu ppc sample defconfigs do (in fact no 2.1.x version).
Yes, you're right, the host-qemu version should be dictated by a config option,
not derived automatically.
Quoted 4 lines
And the qemu config should dictate what's the best version for each - not necessarily the latest, you can't make host-qemu-user depend on that since it's a platform decision, not an arch one.
If you want to stick with "the one that works for everything" you
AFAIK nobody claims that there should be one version that works for everything
- possibly there should even be some version config option for the target qemu. The only problem we see is to have a separate qemu-system and qemu-user package.
Quoted 5 lines
potentially miss the opportunity for new arch and/or platform support. So even if target != host version is fixed/possible you'll still clash on host-qemu (user) vs. host-qemu (system) versions since you might want to do the perl module dance (original purpose of host-qemu) vs. platform emulation.
This one I don't understand. If you need version 2.0.2 for host-qemu-system,
then surely you also need this version for host-qemu-user? So what is the point of treating them as separate packages? Isn't it much easier to build qemu-user and qemu-system in one shot (like how it's done for the target qemu)?
Regards,
Arnout
Quoted 8 lines
It's nice to keep everything in one package, but it's not feasible to do so in a coherent way for this case in particular.
If you can't get the leash out of the qemu version there's no point in building so for the emulation, sometimes you'll ship every single qemu config working, sometimes you wont - and that's my quarrel, everyone is perfect-this perfect-that but all of the sudden this would be acceptable? Like i said it would be the same as $RANDOM distro qemu. Regards.
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
PATCH 1/3 qemu-system: new package
Quoted 10 lines · Arnout Vandecappelle
Quoted 5 lines
potentially miss the opportunity for new arch and/or platform support. So even if target != host version is fixed/possible you'll still clash on host-qemu (user) vs. host-qemu (system) versions since you might want to do the perl module dance (original purpose of host-qemu) vs. platform emulation.
This one I don't understand. If you need version 2.0.2 for host-qemu-system,
then surely you also need this version for host-qemu-user? So what is the point of treating them as separate packages? Isn't it much easier to build qemu-user and qemu-system in one shot (like how it's done for the target qemu)?
The only shared code in qemu for user vs. system is just basically CPU emulation.
For system you've got all of the hardware (audio/ hw/ net/ directories and so on) which isn't used by user at all.
For user it deals with what we can call "ABI" (userland, linux-user/ dir in qemu) which isn't used by system at all, and has arch bits as well. When there are system emulations broken with the latest version of qemu it isn't necessarily a problem with the cpu emulation, the same can happen to user emulation without affecting system.
So if you're like 100% sure user both will work right if system does for X version go ahead, i don't think it's a safe assumption. Just google around a bit:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1284344
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668658
Regards.
PATCH 1/3 qemu-system: new package
Quoted 13 lines · Gustavo Zacarias
Quoted 10 lines · Arnout Vandecappelle
Quoted 5 lines
potentially miss the opportunity for new arch and/or platform support. So even if target != host version is fixed/possible you'll still clash on host-qemu (user) vs. host-qemu (system) versions since you might want to do the perl module dance (original purpose of host-qemu) vs. platform emulation.
This one I don't understand. If you need version 2.0.2 for host-qemu-system,
then surely you also need this version for host-qemu-user? So what is the point of treating them as separate packages? Isn't it much easier to build qemu-user and qemu-system in one shot (like how it's done for the target qemu)?
Quoted 14 lines
The only shared code in qemu for user vs. system is just basically CPU emulation.
For system you've got all of the hardware (audio/ hw/net/directories and so on) which isn't used by user at all.
For user it deals with what we can call "ABI" (userland, linux-user/ dir in qemu) which isn't used by system at all, and has arch bits as well. When there are system emulations broken with the latest version of qemu it isn't necessarily a problem with the cpu emulation, the same can happen to user emulation without affecting system.
So if you're like 100% sure user both will work right if system does for X version go ahead, i don't think it's a safe assumption. Just google around a bit:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1284344
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668658
So what I hear you say is that there really is a case for specifying the
qemu-user and qemu-system version separately, and that that's what this whole discussion really is about. And I guess you may want to build at the same time a host-qemu-user of one version and a host-qemu-system of another version, correct?
Still, the .mk file of qemu-user and qemu-system are 90% the same. It would be
nice to be able to factor that out somehow. However, it makes complete sense to have them as separate packages first and merge them later.
So the question is: is the need for separate host-qemu-system and
host-qemu-user versions more important than the additional complexity of specifying a nearly-identical .mk file twice?
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
PATCH 1/3 qemu-system: new package
Dear Arnout Vandecappelle,
Quoted 20 lines · Arnout Vandecappelle
Quoted 6 lines
The only shared code in qemu for user vs. system is just basically CPU emulation.
For system you've got all of the hardware (audio/ hw/net/directories and so on) which isn't used by user at all.
For user it deals with what we can call "ABI" (userland, linux-user/ dir in qemu) which isn't used by system at all, and has arch bits as well.Quoted 8 lines
When there are system emulations broken with the latest version of qemu it isn't necessarily a problem with the cpu emulation, the same can happen to user emulation without affecting system.
So if you're like 100% sure user both will work right if system does for X version go ahead, i don't think it's a safe assumption. Just google around a bit:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1284344
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668658So what I hear you say is that there really is a case for specifying the
qemu-user and qemu-system version separately, and that that's what this whole discussion really is about. And I guess you may want to build at the same time a host-qemu-user of one version and a host-qemu-system of another version, correct?
Quoted 7 lines
Still, the .mk file of qemu-user and qemu-system are 90% the same. It would be
nice to be able to factor that out somehow. However, it makes complete sense to have them as separate packages first and merge them later.So the question is: is the need for separate host-qemu-system and
host-qemu-user versions more important than the additional complexity of specifying a nearly-identical .mk file twice?
Despite Gustavo's explanation, I'm not sure to see what is the need to have a different version for host-qemu-system and host-qemu-user.
If a given version of host-qemu-system works for a given architecture/platform, then surely, host-qemu-user should work for the same architecture. The opposite is obviously not true, but it doesn't matter much: we can keep whatever version gets host-qemu-system working.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/3 qemu-system: new package
Quoted 18 lines · Thomas Petazzoni
Quoted 5 lines · Arnout Vandecappelle
So what I hear you say is that there really is a case for specifying the
qemu-user and qemu-system version separately, and that that's what this whole discussion really is about. And I guess you may want to build at the same time a host-qemu-user of one version and a host-qemu-system of another version, correct?Quoted 7 lines
Still, the .mk file of qemu-user and qemu-system are 90% the same. It would be
nice to be able to factor that out somehow. However, it makes complete sense to have them as separate packages first and merge them later.So the question is: is the need for separate host-qemu-system and
host-qemu-user versions more important than the additional complexity of specifying a nearly-identical .mk file twice?Despite Gustavo's explanation, I'm not sure to see what is the need to have a different version for host-qemu-system and host-qemu-user.
Quoted 6 lines
If a given version of host-qemu-system works for a given architecture/platform, then surely, host-qemu-user should work for the same architecture. The opposite is obviously not true, but it doesn't matter much: we can keep whatever version gets host-qemu-system working.
Thomas
Arnout: yes, the package .mk could very much share everything that's common among them yet still be a separate "package" configuration/parameter-wise.
Thomas: you've got 3 scenarios, the cpu code is broken which won't matter since both user/system will be broken for a given version, user code broken which will matter to user only, hardware code broken which will matter for system only.
Any of those can happen (even everything broken but it's basically the same as the first option).
And if you're doing user-only for cross configure testing or whatnot system won't be able to dictate which version you're using since it's a config option outside of that scope.
To me it seems the decision was taken during the dev days with one-sided arguments (against), but well life is like that sometimes. The side effect is that it pushes my motivation to contribute to buildroot to an all-time low (read that as you wish, in fact it may not even matter).
Regards.
PATCH 1/3 qemu-system: new package
On 20/10/14 03:53, Gustavo Zacarias wrote:
[snip]
Quoted 2 lines
To me it seems the decision was taken during the dev days with one-sided arguments (against), but well life is like that sometimes.
Well, there was nobody to provide counter-arguments. That's why I started the
discussion on the list.
It's very clear that version selection is needed. It's not so clear that a
separate version is really needed for host-qemu-system and host-qemu-user, because:
- there's a slightly larger chance that both system and user are broken;
- we currently anyway don't have version selection for user;
- we can change it later if required.
On the other hand, it's also possible to merge the qemu-system package now and
refactor it back into a single package later. It wouldn't even require legacy handling because the config symbols already start with BR2_PACKAGE_QEMU.
So I'd propose to give Yann some time to produce a unified qemu package, but if
it doesn't come we can still merge your original patch.
Quoted 3 lines
The side effect is that it pushes my motivation to contribute to buildroot to an all-time low (read that as you wish, in fact it may not even matter).
Since you're the #1 buildroot contributor and have been for some time now, it
really does matter!
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
PATCH 1/3 qemu-system: new package
Dear Arnout Vandecappelle,
Quoted 10 lines · Arnout Vandecappelle
Well, there was nobody to provide counter-arguments. That's why I started the
discussion on the list.It's very clear that version selection is needed. It's not so clear that a
separate version is really needed for host-qemu-system and host-qemu-user, because:- there's a slightly larger chance that both system and user are broken;
- we currently anyway don't have version selection for user;
- we can change it later if required.
Quoted 6 lines
On the other hand, it's also possible to merge the qemu-system package now and
refactor it back into a single package later. It wouldn't even require legacy handling because the config symbols already start withBR2_PACKAGE_QEMU.So I'd propose to give Yann some time to produce a unified qemu package, but if
it doesn't come we can still merge your original patch.
I agree. Nothing is set in stone. At first sight, I don't really see a reason to have a separate version for host-qemu-user and host-qemu-system, so let's implement something that uses the same version for both, and if reality proves that it was a bad choice, it will also be time to change.
Quoted 6 lines
Quoted 3 lines
The side effect is that it pushes my motivation to contribute to buildroot to an all-time low (read that as you wish, in fact it may not even matter).
Since you're the #1 buildroot contributor and have been for some time now, it
really does matter!
Yes, it clearly matters. I'm a bit sad to see that this specific story has affected your motivation. However, on this story, you had your own idea, and basically rejected the comments that were made. That's not really the best way to push things forward: maybe doing a concession sometimes helps, and thanks to this concession, you might prove at a later point that people were wrong and you were right from the beginning :)
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/3 qemu-system: new package
Quoted 7 lines · Thomas Petazzoni
Quoted 6 lines
Quoted 3 lines
The side effect is that it pushes my motivation to contribute to buildroot to an all-time low (read that as you wish, in fact it may not even matter).
Since you're the #1 buildroot contributor and have been for some time now, it
really does matter!
Quoted 7 lines
Yes, it clearly matters. I'm a bit sad to see that this specific story has affected your motivation. However, on this story, you had your own idea, and basically rejected the comments that were made. That's not really the best way to push things forward: maybe doing a concession sometimes helps, and thanks to this concession, you might prove at a later point that people were wrong and you were right from the beginning :)
The same can be said the opposite way don't you think?
This patchset has been sitting for almost a year now with no action on the counterproposal from anyone.
The likely outcome is that the feature will still be missing until the next release cycle.
Either the feature is not interesting and/or wanted, or contributors just lack time, with my time being wasted, waiting (possibly not very patiently at times) for someone else to follow-up on the alternative.
I won't make a concession on this because i really don't believe it's the proper course of action, it's that simple, deal with it. It's not that i'm stubborn, i've changed opinion in many occasions, and i'm not seeking to "rub it off" - if i wanted to do so i could just say "hashes" which i've proposed years ago with the idea being very much rejected at the time - i'm not interested in that.
It could be well thought-out from the start without the need to fix issues that were foreseen later.
It's dissapointing to just sum up commits doing banal stuff even if they're important, to then get the cold shoulder when what i feel are interesting or progressive ideas get delayed and/or rejected. My feeling is that i'm just wasting my time if i make any serious effort to improve things, so basically i give up.
At this point i would have hoped that i've earned some trust with my technical choices, but it feels like not.
That doesn't mean i want a blank check on decisions, don't get that interpretation out of it.
In the end it's not the number of commits that count, that's not an indication of who's #1, #3 or anything, it may be fun but that's it. The momentum is what makes projects great.
And mine wrt buildroot has been neutralized, i'll just care about my little ranch: no autobuild fixing except what i break, no improvements except for what i care, no ACKs, no Tested-bys, no #buildroot IRC, no opinions and so on.
Time will tell if i feel like getting back to that or i'll just dial down the notch on general involvement permanently (there's a saying which i think is quite universal "never say never"). Sometimes you win sometimes you lose, in both the project and personal levels.
I hope i've articulated this mail correctly.
Regards.
PATCH 1/3 qemu-system: new package
Dear Gustavo Zacarias,
Quoted 9 lines · Gustavo Zacarias
Quoted 7 lines
Yes, it clearly matters. I'm a bit sad to see that this specific story has affected your motivation. However, on this story, you had your own idea, and basically rejected the comments that were made. That's not really the best way to push things forward: maybe doing a concession sometimes helps, and thanks to this concession, you might prove at a later point that people were wrong and you were right from the beginning :)
The same can be said the opposite way don't you think?
True in some way. But in another way, doing the concession on what gets merged means reducing the "quality" of what we merge. Is this really what we want? If something doesn't comply with the Buildroot coding style and/or principles, should we merge it just because it has been sitting there since one year?
Quoted 4 lines
This patchset has been sitting for almost a year now with no action on the counterproposal from anyone.
The likely outcome is that the feature will still be missing until the next release cycle.
I agree this isn't nice. But again, if there is a pending patch that doesn't satisfy a majority of developers, should we merge it simply because it has been pending for a long time? I'm sure you would agree that we should not merge such a patch, even if that means leaving the feature out of the tree for a while.
Quoted 6 lines
I won't make a concession on this because i really don't believe it's the proper course of action, it's that simple, deal with it. It's not that i'm stubborn, i've changed opinion in many occasions, and i'm not seeking to "rub it off" - if i wanted to do so i could just say "hashes" which i've proposed years ago with the idea being very much rejected at the time - i'm not interested in that.
I don't remember if I was pro or against hashes back at the time. Probably against, since when Yann proposed the patches, I was still a bit hesitant about this feature.
Quoted 9 lines
It's dissapointing to just sum up commits doing banal stuff even if they're important, to then get the cold shoulder when what i feel are interesting or progressive ideas get delayed and/or rejected. My feeling is that i'm just wasting my time if i make any serious effort to improve things, so basically i give up.
At this point i would have hoped that i've earned some trust with my technical choices, but it feels like not.
That doesn't mean i want a blank check on decisions, don't get that interpretation out of it.
You've definitely earned a *lot* of trust, at least to my eyes, and I believe to many of the other Buildroot developers, Peter included. When I see a patch from Gustavo doing something on a package, I typically merge it eyes closed, or only after a quick look at the patch (I never do any testing of your patches, because I know they basically work).
Beyond this qemu stuff, can you list the patch series/things you've tried to push and that haven't been accepted? I think it's good to discuss what caused the frustration.
Quoted 4 lines
In the end it's not the number of commits that count, that's not an indication of who's #1, #3 or anything, it may be fun but that's it. The momentum is what makes projects great.
And mine wrt buildroot has been neutralized, i'll just care about my
Quoted 8 lines
little ranch: no autobuild fixing except what i break, no improvements except for what i care, no ACKs, no Tested-bys, no #buildroot IRC, no opinions and so on.
Time will tell if i feel like getting back to that or i'll just dial down the notch on general involvement permanently (there's a saying which i think is quite universal "never say never"). Sometimes you win sometimes you lose, in both the project and personal levels.
Wow, I must say I'm truly shocked that things have reached this level. This is definitely not where I'd like things to go: your contributions are very very valuable, and I very often need to refer to you for many questions/opinions/feedback on various things we're doing in Buildroot.
Would you still be willing to have a Google Hangout at some point this week to discuss this?
Live discussion very often helps, and it will allow us to exchange our point of views, and see what we can do to resolve things. At some point, it would be really great to meet in person, because I believe you may not realize how much the Buildroot developers value and respect your contribution.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/3 qemu-system: new package
Gustavo, All,
On 2014-10-21 09:16 +0200, Thomas Petazzoni spake thusly:
Quoted 1 line · Gustavo Zacarias
[--SNIP--]
Quoted 10 lines
Quoted 9 lines
It's dissapointing to just sum up commits doing banal stuff even if they're important, to then get the cold shoulder when what i feel are interesting or progressive ideas get delayed and/or rejected. My feeling is that i'm just wasting my time if i make any serious effort to improve things, so basically i give up.
At this point i would have hoped that i've earned some trust with my technical choices, but it feels like not.
That doesn't mean i want a blank check on decisions, don't get that interpretation out of it.
Quoted 2 lines
You've definitely earned a *lot* of trust, at least to my eyes, and I believe to many of the other Buildroot developers, Peter included.
I agree with Thomas: I too highly recognise your expertise, and that has earned you my trust, for all the hard topics you have touched in Buildroot (security, toolchains, weird archs...)
Quoted 4 lines
Quoted 4 lines
In the end it's not the number of commits that count, that's not an indication of who's #1, #3 or anything, it may be fun but that's it. The momentum is what makes projects great.
And mine wrt buildroot has been neutralized, i'll just care about my
Quoted 8 lines
Quoted 8 lines
little ranch: no autobuild fixing except what i break, no improvements except for what i care, no ACKs, no Tested-bys, no #buildroot IRC, no opinions and so on.
Time will tell if i feel like getting back to that or i'll just dial down the notch on general involvement permanently (there's a saying which i think is quite universal "never say never"). Sometimes you win sometimes you lose, in both the project and personal levels.
I am really stunned to read that, and am really sorry you feel like that. :-(
Quoted 4 lines
Wow, I must say I'm truly shocked that things have reached this level. This is definitely not where I'd like things to go: your contributions are very very valuable, and I very often need to refer to you for many questions/opinions/feedback on various things we're doing in Buildroot.
I can only fully concur to what Thomas said.
Quoted 2 lines
Would you still be willing to have a Google Hangout at some point this week to discuss this?
I could try to join, but as I am on the move in the US, it will be a bit difficult for me. Just arrange for a day and time that suits you, and if I am able to, I'll join.
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH 1/3 qemu-system: new package
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Yann" == Yann E MORIN <[email protected]> writes:
Hi,
Sorry for slow response - I've been busy with family stuff since I got home from Dusseldorf. I'm now in the airport leaving for the GSoC summit.
Quoted 6 lines
Quoted 2 lines
You've definitely earned a *lot* of trust, at least to my eyes, and I believe to many of the other Buildroot developers, Peter included.
I agree with Thomas: I too highly recognise your expertise, and that has earned you my trust, for all the hard topics you have touched in Buildroot (security, toolchains, weird archs...)
I think we all do. I in general merge Gustavo's patches very fast as they very rarely have issues.
Quoted 8 lines
Quoted 5 lines
Quoted 5 lines
Time will tell if i feel like getting back to that or i'll just dial down the notch on general involvement permanently (there's a saying which i think is quite universal "never say never"). Sometimes you win sometimes you lose, in both the project and personal levels.
I am really stunned to read that, and am really sorry you feel like that. :-(
So am I! I must say it comes as quite a shock to me.
Quoted 6 lines
Quoted 2 lines
Would you still be willing to have a Google Hangout at some point this week to discuss this?
I could try to join, but as I am on the move in the US, it will be a bit difficult for me. Just arrange for a day and time that suits you, and if I am able to, I'll join.
I'm in the same situation as Yann, but I'll join if at all possible.
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/3 qemu-system: new package
In reply to Thomas PetazzoniQuoted 12 lines · Thomas Petazzoni
Dear Gustavo Zacarias,
Quoted 8 lines · Gustavo Zacarias
Quoted 7 lines
Yes, it clearly matters. I'm a bit sad to see that this specific story has affected your motivation. However, on this story, you had your own idea, and basically rejected the comments that were made. That's not really the best way to push things forward: maybe doing a concession sometimes helps, and thanks to this concession, you might prove at a later point that people were wrong and you were right from the beginning :)
Quoted 7 lines
Quoted 1 line
The same can be said the opposite way don't you think?
True in some way. But in another way, doing the concession on what gets merged means reducing the "quality" of what we merge. Is this really what we want? If something doesn't comply with the Buildroot coding style and/or principles, should we merge it just because it has been sitting there since one year?
I wouldn't say it's really a matter of quality. We (or actually, the committers)
tend to be conservative when it comes to merging. In particular, if any controversy exists over a patch, it just remains sitting in the queue.
It could be debated whether this is a good thing. But it is the way we work at
the moment.
But the end result that such controversial patches stay in patchwork for a long
time, nobody comments on them anymore, so the discussion essentially dies. And then comes along a patchwork cleanup rush, and things get rejected.
As you mention below w.r.t. the hashes, it's very well possible that a year later
the original idea does suddenly get accepted...
Regards,
Arnout
Quoted 23 lines
Quoted 5 lines
This patchset has been sitting for almost a year now with no action on the counterproposal from anyone.
The likely outcome is that the feature will still be missing until the next release cycle.I agree this isn't nice. But again, if there is a pending patch that doesn't satisfy a majority of developers, should we merge it simply because it has been pending for a long time? I'm sure you would agree that we should not merge such a patch, even if that means leaving the feature out of the tree for a while.
Quoted 6 lines
I won't make a concession on this because i really don't believe it's the proper course of action, it's that simple, deal with it. It's not that i'm stubborn, i've changed opinion in many occasions, and i'm not seeking to "rub it off" - if i wanted to do so i could just say "hashes" which i've proposed years ago with the idea being very much rejected at the time - i'm not interested in that.
I don't remember if I was pro or against hashes back at the time. Probably against, since when Yann proposed the patches, I was still a bit hesitant about this feature.
[snip]
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F