On Fri, 19 Sep 2025 16:24:07 +0900, Johannes Berg wrote: > > On Fri, 2025-09-19 at 09:03 +0900, Hajime Tazaki wrote: > > > This doesn't make a lot of sense to me. Why would we even want to build > > > PCI on NOMMU-UML if PCI in general is dependent on MMU now? > > > > > > It's not like ARCH=um with PCI and NOMMU has any value even for testing > > > if such a configuration cannot exist in reality? > > > > totally understand your point. > > > > now I see that we don't have to have this work around by using > > --kconfig_add option to kunit.py. > > > > # like --kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=n (in addition to > > --kconfig_add CONFIG_MMU=n). > > That's not what I mean. I think it should be made impossible to build > the broken code.
okay. # I think now I lost the point... currently, drivers/pci/Kconfig (CONFIG_PCI) marks as depends on MMU, so we cannot select it when CONFIG_MMU=n. but it's different with kunit when using them via kunit.py config, it first adds CONFIG_VIRTIO_UML=y CONFIG_UML_PCI_OVER_VIRTIO=y via tools/testing/kunit/configs/arch_uml.config, and then add CONIFG_MMU=n via --kconfig_add CONFIG_MMU=n. and then execute make ARCH=um olddefconfig, which in turn enables CONFIG_UML_PCI_OVER_VIRTIO. if we append "--kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=n" to kunit.py, it will overwrite the arch_uml.config. # I don't know how kunit handles those appended CONFIG entries, though.. my goal is simple; to test !MMU code via kunit. my original patch or the additional kconfig argument (--kconfig_add) satisfies this goal. > The problem is probably UML_PCI_OVER_VIRTIO selecting UML_PCI selecting > various PCI code, but nothing depends on PCI in the first place. Which > it should, then? I don't understand the 'nothing depends on PCI...' part. care to elaborate ? thanks, -- Hajime
