在 2020/8/10 下午5:03, Greg KH 写道:
On Mon, Aug 10, 2020 at 10:56:48AM +0200, Paolo Bonzini wrote:
On 10/08/20 09:44, Greg KH wrote:
There is more #ifdef CONFIG_CPU_LOONGSON64 in arch/mips/kvm/vz.c, and
more #include "loongson_regs.h" in arch/mips. So while I agree with
Greg that this idiom is quite unusual, it seems to be the expected way
to use this header. I queued the patch.
Or you all could fix it up to work properly like all other #include
lines in the kernel source tree. There's no reason mips should be
"special" here, right?
It's not just this #include, there's a couple dozen mach-* directories;
changing how they work would be up to the MIPS maintainers (CCed), and
it would certainly not be a patch that can be merged in stable@ kernels.
arch/mips/kernel/cpu-probe.c has the same
#ifdef CONFIG_CPU_LOONGSON64
#include <loongson_regs.h>
for example, so apparently they're good with this. So if I don't pick
up the patch to fix the build it would be in all likelihood merged by
MIPS maintainers. The only difference will be how long the build
remains broken and the fact that they need to worry about KVM despite
the presence of a specific maintainer.
Ok, fair enough, but in the long-run, this should probably be fixed up
"properly" if this arch is still being maintained.
MIPS is using another approach to management machine specified headers.
It changes include path per-machine to get ride of the generic one.
I'm a little bit confused about the proper way to do that. I thought the
design
overall, is just fine.
Should we try to migrate it to another style?
Thanks.
- Jiaxun
thanks,
greg k-h
