Skip to contentSkip to conversation

arm64: defconfig: add options for virtualization and containers

PATCH New Riku Voipio 4 participants 5 messages May 27, 2016 – Jun 2, 2016

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 arm64: defconfig: add options for virtualization and containers

Enable options commonly needed by popular virtualization and container applications. Use modules when possible to avoid too much overhead for users not interested.

- add namespace and cgroup options needed
- add seccomp - optional, but enhances Qemu etc
- bridge, nat, veth, macvtap and multicast for routing guests and containers
- btfrs and overlayfs modules for container COW backends
- while near it, make fuse a module instead of built-in.

Generated with make saveconfig and dropping unrelated spurious change hunks while commiting. bloat-o-meter old-vmlinux vmlinux:

add/remove: 899/388 grow/shrink: 744/216 up/down: 183556/-94881 (88675)
...
Total: Before=10515333, After=10604008, chg 0.000000%

---
 arch/arm64/configs/defconfig | 53 +++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 47 insertions(+), 6 deletions(-)
arch/arm64/configs/defconfig +47 -6
index fd2d74d..7db8010 100644
@@ -15,10 +15,14 @@ CONFIG_IKCONFIG_PROC=y
 CONFIG_LOG_BUF_SHIFT=14
 CONFIG_MEMCG=y
 CONFIG_MEMCG_SWAP=y
+CONFIG_BLK_CGROUP=y
+CONFIG_CGROUP_PIDS=y
 CONFIG_CGROUP_HUGETLB=y
-# CONFIG_UTS_NS is not set
-# CONFIG_IPC_NS is not set
-# CONFIG_NET_NS is not set
+CONFIG_CPUSETS=y
+CONFIG_CGROUP_DEVICE=y
+CONFIG_CGROUP_CPUACCT=y
+CONFIG_CGROUP_PERF=y
+CONFIG_USER_NS=y
 CONFIG_SCHED_AUTOGROUP=y
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_KALLSYMS_ALL=y
@@ -69,6 +73,7 @@ CONFIG_PREEMPT=y
 CONFIG_KSM=y
 CONFIG_TRANSPARENT_HUGEPAGE=y
 CONFIG_CMA=y
+CONFIG_SECCOMP=y
 CONFIG_XEN=y
 # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
 CONFIG_COMPAT=y
@@ -81,10 +86,37 @@ CONFIG_NET=y
 CONFIG_PACKET=y
 CONFIG_UNIX=y
 CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
 CONFIG_IP_PNP=y
 CONFIG_IP_PNP_DHCP=y
 CONFIG_IP_PNP_BOOTP=y
-# CONFIG_IPV6 is not set
+CONFIG_IPV6=m
+CONFIG_NETFILTER=y
+CONFIG_NF_CONNTRACK=m
+CONFIG_NF_CONNTRACK_EVENTS=y
+CONFIG_NETFILTER_XT_TARGET_CHECKSUM=m
+CONFIG_NETFILTER_XT_TARGET_LOG=m
+CONFIG_NETFILTER_XT_MATCH_ADDRTYPE=m
+CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
+CONFIG_NF_CONNTRACK_IPV4=m
+CONFIG_IP_NF_IPTABLES=m
+CONFIG_IP_NF_FILTER=m
+CONFIG_IP_NF_TARGET_REJECT=m
+CONFIG_IP_NF_NAT=m
+CONFIG_IP_NF_TARGET_MASQUERADE=m
+CONFIG_IP_NF_MANGLE=m
+CONFIG_NF_CONNTRACK_IPV6=m
+CONFIG_IP6_NF_IPTABLES=m
+CONFIG_IP6_NF_FILTER=m
+CONFIG_IP6_NF_TARGET_REJECT=m
+CONFIG_IP6_NF_MANGLE=m
+CONFIG_IP6_NF_NAT=m
+CONFIG_IP6_NF_TARGET_MASQUERADE=m
+CONFIG_BRIDGE=m
+CONFIG_BRIDGE_VLAN_FILTERING=y
+CONFIG_VLAN_8021Q=m
+CONFIG_VLAN_8021Q_GVRP=y
+CONFIG_VLAN_8021Q_MVRP=y
 CONFIG_BPF_JIT=y
 CONFIG_CFG80211=m
 CONFIG_MAC80211=m
@@ -100,6 +132,7 @@ CONFIG_MTD=y
 CONFIG_MTD_M25P80=y
 CONFIG_MTD_SPI_NOR=y
 CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_NBD=m
 CONFIG_VIRTIO_BLK=y
 # CONFIG_SCSI_PROC_FS is not set
 CONFIG_BLK_DEV_SD=y
@@ -116,7 +149,10 @@ CONFIG_SATA_SIL24=y
 CONFIG_PATA_PLATFORM=y
 CONFIG_PATA_OF_PLATFORM=y
 CONFIG_NETDEVICES=y
+CONFIG_MACVLAN=m
+CONFIG_MACVTAP=m
 CONFIG_TUN=y
+CONFIG_VETH=m
 CONFIG_VIRTIO_NET=y
 CONFIG_AMD_XGBE=y
 CONFIG_NET_XGENE=y
@@ -144,6 +180,7 @@ CONFIG_INPUT_EVDEV=y
 CONFIG_KEYBOARD_GPIO=y
 # CONFIG_SERIO_SERPORT is not set
 CONFIG_SERIO_AMBAKMI=y
+CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
 CONFIG_LEGACY_PTY_COUNT=16
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
@@ -304,12 +341,16 @@ CONFIG_ARM_SCPI_PROTOCOL=y
 CONFIG_ACPI=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
+CONFIG_EXT4_FS_POSIX_ACL=y
+CONFIG_BTRFS_FS=m
+CONFIG_BTRFS_FS_POSIX_ACL=y
 CONFIG_FANOTIFY=y
 CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y
 CONFIG_QUOTA=y
 CONFIG_AUTOFS4_FS=y
-CONFIG_FUSE_FS=y
-CONFIG_CUSE=y
+CONFIG_FUSE_FS=m
+CONFIG_CUSE=m
+CONFIG_OVERLAY_FS=m
 CONFIG_VFAT_FS=y
 CONFIG_TMPFS=y
 CONFIG_HUGETLBFS=y
Signature · 1 line
2.1.4
#1 lore raw

PATCH 1/1 arm64: defconfig: add options for virtualization and containers

Quoted 14 lines · Riku Voipio

Enable options commonly needed by popular virtualization and container applications. Use modules when possible to avoid too much overhead for users not interested.

- add namespace and cgroup options needed
- add seccomp - optional, but enhances Qemu etc
- bridge, nat, veth, macvtap and multicast for routing guests and containers
- btfrs and overlayfs modules for container COW backends
- while near it, make fuse a module instead of built-in.

Generated with make saveconfig and dropping unrelated spurious change hunks while commiting. bloat-o-meter old-vmlinux vmlinux:

Quoted 8 lines

add/remove: 899/388 grow/shrink: 744/216 up/down: 183556/-94881 (88675)
...
Total: Before=10515333, After=10604008, chg 0.000000%

---
 arch/arm64/configs/defconfig | 53 +++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 47 insertions(+), 6 deletions(-)

I'm fine with adding stuff to defconfig if it's useful to people (and it looks like this is), but it's probably about time we figured out what to do about '=y' vs '=m'. Until recently (i.e. this merge window), the arm64 defconfig didn't build any modules. Obviously this only scales so far, since the Image tends to get rather huge, but it would be good to try and establish a rule-of-thumb as to whether we treat something as a module or a built-in. We could even consider retrospectively applying the rule if its straightforward enough.

One easy way to do it would be: if you need the option to boot, then it's a built-in, but that brings up questions around "boot a full android system" vs "boot to a point where you could load an initrd".

Any ideas? Am I mad trying to put method into madness?

Will

#2 lore raw

PATCH 1/1 arm64: defconfig: add options for virtualization and containers

Quoted 33 lines · Will Deacon
Quoted 14 lines · Riku Voipio

Enable options commonly needed by popular virtualization and container applications. Use modules when possible to avoid too much overhead for users not interested.

- add namespace and cgroup options needed
- add seccomp - optional, but enhances Qemu etc
- bridge, nat, veth, macvtap and multicast for routing guests and containers
- btfrs and overlayfs modules for container COW backends
- while near it, make fuse a module instead of built-in.

Generated with make saveconfig and dropping unrelated spurious change hunks while commiting. bloat-o-meter old-vmlinux vmlinux:

Quoted 8 lines

add/remove: 899/388 grow/shrink: 744/216 up/down: 183556/-94881 (88675)
...
Total: Before=10515333, After=10604008, chg 0.000000%

---
 arch/arm64/configs/defconfig | 53 +++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 47 insertions(+), 6 deletions(-)

I'm fine with adding stuff to defconfig if it's useful to people (and it looks like this is), but it's probably about time we figured out what to do about '=y' vs '=m'. Until recently (i.e. this merge window), the arm64 defconfig didn't build any modules. Obviously this only scales so far, since the Image tends to get rather huge, but it would be good to try and establish a rule-of-thumb as to whether we treat something as a module or a built-in. We could even consider retrospectively applying the rule if its straightforward enough.

Quoted 3 lines

One easy way to do it would be: if you need the option to boot, then it's a built-in, but that brings up questions around "boot a full android system" vs "boot to a point where you could load an initrd".

For the time being, I would say defconfig should cover "boot to a login prompt" where this may imply NFS + network driver built in for the supported SoCs, couple of commonly used filesystems (ext4, btrfs). The rest can be enabled as modules.

As the image continues to grow over years, we will have to revisit this and possibly separate the mobile from the server SoC defconfig. For the former, we can probably keep the same "boot to a login prompt" approach. For the latter, especially if you install it under a distro (e.g. you do make deb-pkg or rpm-pkg), we can aim for "boot to initramfs". That said, I'd like to see most of the SoC drivers stuff built as modules (whatever is not essential for booting to initramfs and comes in at device_initcall level).

Signature · 1 line
Catalin
#3 lore raw

PATCH 1/1 arm64: defconfig: add options for virtualization and containers

Quoted 34 lines · Catalin Marinas
Quoted 33 lines · Will Deacon
Quoted 14 lines · Riku Voipio

Enable options commonly needed by popular virtualization and container applications. Use modules when possible to avoid too much overhead for users not interested.

- add namespace and cgroup options needed
- add seccomp - optional, but enhances Qemu etc
- bridge, nat, veth, macvtap and multicast for routing guests and containers
- btfrs and overlayfs modules for container COW backends
- while near it, make fuse a module instead of built-in.

Generated with make saveconfig and dropping unrelated spurious change hunks while commiting. bloat-o-meter old-vmlinux vmlinux:

Quoted 8 lines

add/remove: 899/388 grow/shrink: 744/216 up/down: 183556/-94881 (88675)
...
Total: Before=10515333, After=10604008, chg 0.000000%

---
 arch/arm64/configs/defconfig | 53 +++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 47 insertions(+), 6 deletions(-)

I'm fine with adding stuff to defconfig if it's useful to people (and it looks like this is), but it's probably about time we figured out what to do about '=y' vs '=m'. Until recently (i.e. this merge window), the arm64 defconfig didn't build any modules. Obviously this only scales so far, since the Image tends to get rather huge, but it would be good to try and establish a rule-of-thumb as to whether we treat something as a module or a built-in. We could even consider retrospectively applying the rule if its straightforward enough.

Quoted 8 lines
Quoted 3 lines

One easy way to do it would be: if you need the option to boot, then it's a built-in, but that brings up questions around "boot a full android system" vs "boot to a point where you could load an initrd".

For the time being, I would say defconfig should cover "boot to a login prompt" where this may imply NFS + network driver built in for the supported SoCs, couple of commonly used filesystems (ext4, btrfs). The rest can be enabled as modules.

Sounds like a good rule of thumb. This is roughly what I've followed in my patch. Some options can only be enabled as built-in, such as cgroup/namespace/seccomp options. I think for these, setting them as =y makes sense since major distributions do it also. Distributions make everything possible as modules, so having something built-in is pretty strong vote for the feature to be built-in the kernel.

Quoted 11 lines

As the image continues to grow over years, we will have to revisit this and possibly separate the mobile from the server SoC defconfig. For the former, we can probably keep the same "boot to a login prompt" approach. For the latter, especially if you install it under a distro (e.g. you do make deb-pkg or rpm-pkg), we can aim for "boot to initramfs". That said, I'd like to see most of the SoC drivers stuff built as modules (whatever is not essential for booting to initramfs and comes in at device_initcall level).

--
Catalin

#4 lore raw

PATCH 1/1 arm64: defconfig: add options for virtualization and containers

In reply to Catalin Marinas
Quoted 34 lines · Catalin Marinas
Quoted 33 lines · Will Deacon
Quoted 14 lines · Riku Voipio

Enable options commonly needed by popular virtualization and container applications. Use modules when possible to avoid too much overhead for users not interested.

- add namespace and cgroup options needed
- add seccomp - optional, but enhances Qemu etc
- bridge, nat, veth, macvtap and multicast for routing guests and containers
- btfrs and overlayfs modules for container COW backends
- while near it, make fuse a module instead of built-in.

Generated with make saveconfig and dropping unrelated spurious change hunks while commiting. bloat-o-meter old-vmlinux vmlinux:

Quoted 8 lines

add/remove: 899/388 grow/shrink: 744/216 up/down: 183556/-94881 (88675)
...
Total: Before=10515333, After=10604008, chg 0.000000%

---
 arch/arm64/configs/defconfig | 53 +++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 47 insertions(+), 6 deletions(-)

I'm fine with adding stuff to defconfig if it's useful to people (and it looks like this is), but it's probably about time we figured out what to do about '=y' vs '=m'. Until recently (i.e. this merge window), the arm64 defconfig didn't build any modules. Obviously this only scales so far, since the Image tends to get rather huge, but it would be good to try and establish a rule-of-thumb as to whether we treat something as a module or a built-in. We could even consider retrospectively applying the rule if its straightforward enough.

Quoted 8 lines
Quoted 3 lines

One easy way to do it would be: if you need the option to boot, then it's a built-in, but that brings up questions around "boot a full android system" vs "boot to a point where you could load an initrd".

For the time being, I would say defconfig should cover "boot to a login prompt" where this may imply NFS + network driver built in for the supported SoCs, couple of commonly used filesystems (ext4, btrfs). The rest can be enabled as modules.

Agreed, with the addition of reasonable options for block devices used for said native rootfs.

Quoted 8 lines

As the image continues to grow over years, we will have to revisit this and possibly separate the mobile from the server SoC defconfig. For the former, we can probably keep the same "boot to a login prompt" approach. For the latter, especially if you install it under a distro (e.g. you do make deb-pkg or rpm-pkg), we can aim for "boot to initramfs". That said, I'd like to see most of the SoC drivers stuff built as modules (whatever is not essential for booting to initramfs and comes in at device_initcall level).

I'm all for modules, but I do prefer a world in which initramfs is still optional with defconfig. However, as you say that can be reconsidered down the road if needed.

-Olof