Investigate why we need CONFIG_SHMEM=y

[shenki]

@amboar wrote:

Subject: [PATCH] aspeed_defconfig: Enable SHMEM and TMPFS

Without enabling these options we get strange behaviour under qemu,
where it appears uevents aren't generated to create device nodes for
ttyS{0,4,5}. As a consequence we don't receive a getty on the console.

C=C3=A9dric narrowed down the list of options initially at [1],
and with a patch to the qemu timer model[2] we can retain the
CONFIG_NO_HZ_IDLE=3Dy configuration.

[1] openbmc/qemu#4
[2] https://lists.ozlabs.org/pipermail/openbmc/2016-May/003209.html

The CONFIG_SHMEM Kconfig has this to say:

CONFIG_SHMEM: │
The shmem is an internal filesystem used to manage shared memory.
It is backed by swap and manages resource limits. It is also exported
to userspace as tmpfs if TMPFS is enabled. Disabling this
option replaces shmem and tmpfs with the much simpler ramfs code,
which may be appropriate on small systems without swap.

This suggests that when we disable SHMEM we should still be okay, and as we're a "small system without swap" this is an appropriate thing to disable. Perhaps there is some breakage upstream?

[williamspatrick]

I thought systemd might use it, but when I look at my desktop it is only used for pulseaudio. My system has /dev/shm mounted as tmpfs though.

[williamspatrick]

Oh, this disables tmpfs. We want that over ramfs.

[mdmillerii]

It enables full tmpfs with swap backing. A basic tmpfs is supposed to be enabled without it.