[PATCH] arm64: defconfig: add options for virtualization and containers

[Olof Johansson]

On Tue, May 31, 2016 at 7:23 AM, Catalin Marinas
<catalin.marinas at arm.com> wrote:
> On Tue, May 31, 2016 at 02:57:41PM +0100, Will Deacon wrote:
>> On Fri, May 27, 2016 at 01:42:27PM +0300, Riku Voipio wrote:
>> > 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%
>> >
>> > Signed-off-by: Riku Voipio <riku.voipio at linaro.org>
>> > ---
>> >  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".
>
> 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.

> 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