On 26/02/2021 15:30, Bob Eshleman wrote: > On 2/25/21 3:14 PM, Andrew Cooper wrote: >> Well - this is orders of magnitude more complicated than it ought to >> be. An empty head.S doesn't (well - shouldn't) need the overwhelming >> majority of this. >> >> Do you know how all of this is being pulled in? Is it from attempting >> to compile common/ by any chance? >> >> Now is also an excellent opportunity to nuke the x86isms which have >> escaped into common code (debugger and xenoprof in particular), and >> rethink some of our common/arch split. >> >> When it comes to header files specifically, I want to start using >> xen/arch/$ARCH/include/asm/ and retrofit this to x86 and ARM. It has >> two important properties - first, that you don't need to symlink the >> tree to make compilation work, and second that patches touching multiple >> architectures have hunks ordered in a more logical way. >> >> ~Andrew >> > I think we may have envisioned different things here.... I was under > the impression that we wanted to implicate common, so that changes > there that broke the RISC-V build would present themselves on CI... > and to demonstrate which "arch_*" calls common expects to exist. > > It sounds like you'd prefer no common to start and none of the > arch_* calls it relies on?
We definitely want "stuff compiled under RISC-V" to be caught in CI, but that doesn't mean "wedge all of common in with stubs to begin with". Honestly - I want to see the build issues/failures in common, to help us fix the rough corners on Kconfig system and include hierarchy. In light of this patch, there are definitely some things which should be fixed as prerequisites, rather than forcing yet-more x86-isms into every new arch. ~Andrew
