On 28.04.21 11:30, Thomas Huth wrote:
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.
I think anybody uses the sclp console nowadays. The only question is, do
we care about manual configs with virtio-console?
