[OpenWrt-Devel] [PATCH 2/5] build: image: Add pad-to and pad-rootfs-squashfs helpers

[Petr Štetiar]

Jo-Philipp Wich <jo at mein.io> [2019-04-01 07:33:40]:

> Most other targets ship image artifacts which are usable ootb, requiring
> one extra step to pad the combined images is a waste of user resources
> every single time. It also causes recurring confusion among users
> wanting to use x86 builds

x86, armvirt and malta builds to be more specific

> I really don't see the huge problem with conservatively padding the
> combined image artifacts to something like 32 or 48MB, it must not even
> be 256M or more.

Felix had a good point about sysupgrade, where we would needlesly write few
dozen MBs of 0s. In order to avoid that, I would simply add following qemu
variants to x86:

 openwrt-x86-{64,generic,geode,legacy}-qemu-{rootfs,combined}-squashfs.img

and produce padded squashfs rootfs images for QEMU only targets by default:

 openwrt-armvirt-{32,64}-rootfs-squashfs.img
 openwrt-malta-{be,be64,le,le64}-rootfs-squashfs.img

I'm wondering if we should introduce CONFIG_QEMU_SQUASHFS_PARTSIZE=32 and use
this information for generating of images for QEMU.

Without this config option I don't see, how could we handle this on x86. On
armvirt/malta we could probably just set already available option
CONFIG_TARGET_ROOTFS_PARTSIZE=32 and use that to pad the images.

Or should we just forget about this QEMU specific CONFIG_QEMU_SQUASHFS_PARTSIZE
and use CONFIG_TARGET_ROOTFS_PARTSIZE for QEMU images as well? We can decrease
the default 256M to 32M on armvirt/malta.

-- ynezz

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel