On Mon, Aug 10, 2020 at 11:03:10AM +0200, Greg KH wrote: > 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. I have it on my todo list. My plan is to move stuff out of mach-* directories, which aren't needed there. This should solve issues like the one here. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ]
