On 28/04/2021 10.31, Christian Borntraeger wrote:
On 28.04.21 10:24, Thomas Huth wrote:In former times, the virtio-console code had to be compiled into the kernel since the old guest virtio transport had some hard de- pendencies. But since the old virtio transport has been removed in commit 7fb2b2d51244 ("s390/virtio: remove the old KVM virtio transport"), we do not have this limitation anymore. Commit bb533ec8bacd ("s390/config: do not select VIRTIO_CONSOLE via Kconfig") then also lifted the hard setting in the Kconfig system, so we can finally switch the CONFIG_VIRTIO_CONSOLE knob to compile this driver as a module now, making it more flexible for the user to only load it if it is really required.Isnt that a distro specific decision? I would be perfectly fine to have this change in Fedora, Redhat and co.
Sure, I'll try to get it changed there, too.
Not so sure about defconfig. We often use the defconfig in our CI and development things to have a kernel config that boots up fine, even without a ramdisk. I agree that virtio console is no longer really the most important console but does it really hurt?
Well, it's about a default configuration that should be fine for most users. I don't think that anybody really uses virtio-console in a ramdisk already ... or are you really doing that in your CI? If so, then please disregard my patch.
Otherwise, I think compiling this as a module is the better choice, since most people won't use this at all during run-time, or maybe just use it for thing like communicating with the QEMU guest agent, but this is then certainly not required during boot up yet and thus the "m" should be fine, too.
Is any distro using the defconfig unmodified?
Most likely don't. But it's a template for new configs, so we should use good defaults here.
Thomas
