RFC: Additions to APIC driver

From: Steffen Persvold
Date: Thu Jun 25 2015 - 12:54:33 EST


Hi,

Weâre preparing our APIC driver (arch/x86/kernel/apic/apic_numachip.c) with next-gen hardware support and in that process I have a question on what the cleanest approach would be.

Both current generation and next generation chips will share a lot of similar code, but some of the core functionality is slightly different (such as the address to which you communicate with the APIC ICR to send IPIs, how to derive APIC IDs etc.).

The way I see it, we have few alternatives :

1) Create a new arc/x86/kernel/apic/apic_numachip2.c (and corresponding entry in the Makefile) which has a new âstruct apicâ with function pointers to the next-gen specific code. The new APIC driver would still only need CONFIG_X86_NUMACHIP to be compiled.

2) Modify the existing apic_numachip.c to recognise the different HW generations (trivial) and use function pointers to differentiate the IPI send calls (among other things), but use the *same* âstruct apicâ for both (the function pointers referenced in âstruct apicâ would need a new indirection level to differentiate between hardware revs).

3) Have two different âstruct apicâ entries in the existing apic_numachip.c source file, with separate oem_madt check functions etc. This would only be marginally different than 1) as far as implementation and code duplication goes, but it would be contained to one C source file and object file (silly question, maybe: would the apic_driver enumeration even work if itâs all in the same object file?)

Any insight into this from the great minds behind this would be highly appreciated.

Kind regards,
--
Steffen Persvold
Chief Architect NumaChip, Numascale AS
Tel: +47 23 16 71 88 Fax: +47 23 16 71 80 Skype: spersvold

--
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/