On 20 July 2017 at 12:17, Markus Armbruster <arm...@redhat.com> wrote: > Peter Maydell <peter.mayd...@linaro.org> writes: > >> The current CONFIG_IVSHMEM is confusing, because it looks like it's a >> flag for "do we have ivshmem support?", but actually it's a flag for >> "is the ivshmem PCI device being compiled?" (and implicitly "do we >> have ivshmem support?" is tested with CONFIG_EVENTFD). >> >> Rename it to CONFIG_IVSHMEM_DEVICE to clear this confusion up; >> shortly we will add a new CONFIG_IVSHMEM which really does indicate >> whether the host can support ivshmem. >> >> Signed-off-by: Peter Maydell <peter.mayd...@linaro.org> > > I don't really care how we name this macro, but I can't help to > wonder... We have many CONFIG_<dev>. The pci.mak context even shows > some. Why is <dev> = IVSHMEM confusing? Why is <dev> = EDU *not* > confusing?
Well, this did confuse the people involved in trying to fix this bug first time round, because we tried to add an "ifdef CONFIG_IVSHMEM" guard to the Makefile lines that defnie the rules for ivshmem-client and ivshmem-server, and it it fails in obscure and confusing ways because CONFIG_IVSHMEM doesn't mean "ivshmem OK", it means only "this particular foo-softmmu build has the ivshmem device in it". Basically, it looks like a global config flag but it isn't (because ivshmem has globally built parts, ie the tools, as well as the device itself, and configure tests that control whether it can be built or not) whereas nobody thinks CONFIG_EDU is something that should control global parts of the build because the device is only the device and the host config doesn't matter. thanks -- PMM
