On Mon, 28 Jul 2025 at 20:34, Pierrick Bouvier <pierrick.bouv...@linaro.org> wrote: > This old commit (7702e47c2) was the origin of having interrupt related > code in a generic folder, but I don't really understand the rationale > behind it to be honest. It seems to be an exception regarding all the > rest of the codebase, thus the idea to bring back things where they belong.
Most devices are both (a) architecture specific and (b) a particular kind of device (UART, ethernet controller, interrupt controller, etc). The nature of a filesystem hierarchy is that we can't file them in both ways at once. We picked "sort them by kind", which is why all the interrupt controllers live in hw/intc, all the UARTS in hw/char, ethernet controllers in hw/net, and so on. In this breakdown of the world, hw/$ARCH is supposed to be for board models and SoC models only. The GICv3 and the NVIC are odd, because they are very closely coupled to the CPU. (A few other interrupt controllers are also like this, but many are not: for instance the GICv2 is a distinct bit of hardware that communicates with the CPU over the IRQ and FIQ lines only.) One of my post-implementation regrets about GICv3 is that we didn't really get the split between the GICv3 proper and its CPU interface right. In hardware the GICv3 is an external device and the CPU interface is part of the CPU, with a defined protocol for talking between them. In QEMU we put all the implementation of this in hw/intc/, and the code in arm_gicv3_cpuif.c does some ad-hoc installing of hooks into the CPU. For the GICv5 I'm trying to structure this in a cleaner way that is closer to the hardware structure, so the CPU interface will be code in target/arm/, with a clearly defined set of functions that it calls to talk to the rest of the GIC that lives in hw/intc/. (This would be too much upheaval to retrofit to GICv3 though, I think.) In a green-field design of M-profile we might have made the NVIC be code in target/arm, and instead of a separate device have the CPU object itself do this code. But at the time it was written we didn't have the same QOM device class setup we did at the time, and IIRC CPU objects weren't a subclass of device. > As well, I would prefer having a clean build system more than a clear > filesystem structure, considering it's quite easy to jump into any > definition automatically with your work editor nowadays, vs understand a > meson.build file full of tricks and implicit dependencies where no tool > can help you. On the other hand, I prefer to have the source files in a clear structure, because then you know where to find things, and command line tools like grep etc are easier to use. (I don't use editor jump-to-definition: I've never felt the need to try to set it up.) Build system files on the other hand are things that most people don't need to look at or do more than very simple "add another file in the same pattern as the existing ones", so it's not too bad if they accumulate a little complexity. Looking at hw/intc, there is a lot of use of specific_ss here, so I suspect that these Arm interrupt controllers are not going to be the only ones that are using target-dependent code (there are 25 files which use CPUState, for instance). So I think it's worth figuring out how to build these in the right way where they are rather than saying that various interrupt controller models should move to a place where they don't logically belong because that happens to be a folder where we have the build machinery for it. thanks -- PMM
