Am 15.05.2015 um 07:43 schrieb Peter Crosthwaite: > On Sun, May 10, 2015 at 11:29 PM, Peter Crosthwaite > <crosthwaitepe...@gmail.com> wrote: >> These are architecture specific, and via cpu.h visibile in common >> and global namespaces. Preface them with "ARMAR_" to avoid namespace >> collisions. Prepares support for multi-arch where multiple cpu.h's >> can be included by device land code and namespace issues happen with >> such generic names. >> >> Use prefix ARM"AR" as the trap table is separate from the M-profile >> support, so qualify with AR to make it specific to A/R profile.
ARM_AR_ would sound more appealing to me. > So I am not exactly sure what to do here going forward. This is going > to get messy with all the other arches. There are alternatives: > > 1: Split these arch-specific private defs to a new header. internals.h > or a new header. which every way we go though the header needs to be > exported to linux-user code (awkward). > 2: Purge all device-land uses of cpu.h. They should be able to use > cpu-qom.h Negative, my plans to make cpu-qom.h generally usable failed as env turned out as embedded struct rather than pointer, and cpu-qom.h thus depends on stuff defined in cpu.h before its inclusion of cpu-qom.h. Therefore I told contributors of new targets that the current split makes no sense for their new targets. I would prefer 1. independent of whether we rename them or not. We need a better distinction of internal vs. external for targets. Regards, Andreas > and the random bits of machine-model code reaching into the > env or strobing interrupts needs to be fixed. > 3: This patch or something like it. > > Regards, > Peter -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg)
