On 10/27/2026 7:03 PM, Yonggang Luo wrote: > On Wed, Oct 28, 2026 at 2:31 AM Pierrick Bouvier > <[email protected]> wrote: >> >> On 10/26/2026 9:40 PM, Yonggang Luo wrote: >>> Now we need use the prepared target-list to register different >>> accel-$cpu_type >>> parent QOM type. So that multi-target won't error missing parent for >>> different >>> accel for different arch. >>> >>> Also add a test for it in test-multi-target.c >>> >>> Signed-off-by: Yonggang Luo <[email protected]> >>> --- >>> accel/accel-common.c | 6 ++---- >>> accel/accel-internal.h | 1 + >>> accel/accel-system.c | 24 ++++++++++++++++++++++++ >>> accel/accel-user.c | 7 +++++++ >>> tests/unit/test-multi-target.c | 15 +++++++++++++++ >>> 5 files changed, 49 insertions(+), 4 deletions(-) >>> >> >> An alternative would be to keep a target specific accel file >> (accel-target.c), which only contains code registration for accel type, >> and no global symbols. >> >> This way, the type is correctly present for all targets, without needing >> to iterate list of targets explicitly, as build system includes what is >> needed directly. >> >> IMHO, it would be simpler and better. >> >> What do you think? > > I am fine with this, I also consider this, I have avoided this because > I am thinking > there won't any target-specific files except target-info-def.c in the > remote future. > Now I think a small set of this type(target-specific) of files is also > acceptable, > I'll go this way, much simpler. >
Sounds good. As long as a file does not introduce global symbols, it's not really a problem to have target-specific files. >> >> >> Regards, >> Pierrick > > >
