On (Fri) 25 Feb 2011 [12:13:20], Chuck Ebbert wrote: > On Fri, 25 Feb 2011 11:38:15 +0530 > Amit Shah <amit.shah@xxxxxxxxxx> wrote: > > > On (Thu) 24 Feb 2011 [11:28:19], Chuck Ebbert wrote: > > > The virtio configuration options are inconsistent. According to this, > > > every options that needs virtio will select it: > > > > > > # Virtio always gets selected by whoever wants it. > > > config VIRTIO > > > tristate > > > > > > Note that it's not user-selectable, so any config file that tries to > > > set it will be ignored when kconfig loads those options. And yet we > > > have a whole set of options that depend on VIRTIO, like VIRTIO_CONSOLE > > > for example. This makes it impossible to have VIRTIO_PCI modular and > > > VIRTIO_CONSOLE built-in on x86_64, because: > > > > Any reason to have VIRTIO_PCI modular instead of built in (on x86-64, > > virtio-console won't work without virtio-pci anyway)? > > > > None that I know of offhand, other than not building in things unless > absolutely necessary. There's no dependency of any kind there, so it's > even possible to build a kernel with VIRTIO_CONSOLE enabled and > VIRTIO_PCI completely disabled. Yes, that's that way because not all architectures need virtio-pci to have virtio-console functional (eg. s390, which doesn't have a PCI bus). So if you're only interested in the x86-64 arch, you could compile in virtio-pci and virtio-console and this should happily work. Amit _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization