[RFC] Making more drivers compile on x86

From: Matthew Wilcox
Date: Wed Sep 10 2014 - 12:11:39 EST



In Chicago, there was a brief discussion about making more drivers
compile on architectures where there was no possible way they could run
(since the relevant hardware does not exist for those platforms).

I have recently needed to compile-test axonram and dcssblk, which rely
on hardware unique to powerpc and s390, respectively. As promised in
the discussion, here is the patch I use to do that. Since it was for
my own purposes, I didn't do anything fancy like wrap the faked parts
in #ifdef COMPILE_TEST.

Hopefully this will be useful grist for the mill. Looking the patch
over, if I were proposing something to be merged, I think I'd make much
more use of prototypes, and less of macros. It would probably also make
sense to put extmem in asm-generic, rather than replicate it for each
architecture that wants to have a more "full" compile test.

--- /dev/null 2013-12-18 16:49:55.714859099 -0500
+++ b/arch/x86/include/asm/extmem.h 2013-12-19 16:49:44.000000000 -0500
@@ -0,0 +1,10 @@
+#define SEGMENT_EXCLUSIVE 1
+#define SEG_TYPE_ER 2
+#define SEGMENT_SHARED 3
+#define SEG_TYPE_SR 4
+#define SEG_TYPE_SC 5
+#define segment_warning(x, y) do { } while (0)
+int segment_load(char *x, int y, unsigned long *z, unsigned long *a);
+#define segment_unload(x) do { } while (0)
+#define segment_modify_shared(x, y) 0
+#define segment_save(x) do { } while (0)
diff --git a/arch/x86/include/asm/prom.h b/arch/x86/include/asm/prom.h
index fbeb06e..dc6191f 100644
--- a/arch/x86/include/asm/prom.h
+++ b/arch/x86/include/asm/prom.h
@@ -37,6 +37,11 @@ static inline void x86_dtb_init(void) { }
#define of_ioapic 0
#endif

+#define _PAGE_NO_CACHE 1
+#define NO_IRQ 2
+extern int of_address_to_resource(void *x, int y, struct resource *z);
+#define irq_of_parse_and_map(x, y) 0
+
extern char cmd_line[COMMAND_LINE_SIZE];

#endif /* __ASSEMBLY__ */

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/