Closed metin-arm closed 7 months ago
This should probably be implemented as a Platform
rather than a Target
, as this handles "hardware" rather than OS-level functionality; And that way, the same code can be used for Android targets running on QEMU as well.
@setrofim I'm not sure platform would be appropriate either, we want an object that starts its life before the Target
and survives after. Platform seems to be more for managing platform-specific interaction with a device (such as rebooting) more than spawning the device itself.
we want an object that starts its life before the Target and survives after
A Platform
is passed a a parameter on Target
creation, so it is already assumed to exist before the Target
(only if one is not provided, the Target
will then create a "default" one). And the Target
doesn't do anything to "terminate" a Platform
, so there is no reason why the latter can't persist after the former stopped existing.
Platform seems to be more for managing platform-specific interaction with a device (such as rebooting) more than spawning the device itself.
Only because a device is not normally "spawned". However the interactions can include the initial target setup prior to execution (e.g. flashing images -- see VExpress platform). Support for Gem5 simulation (conceptually similar to QEMU) is implemented as a Platform
and that includes optionally starting the simulation.
@douglas-raillard-arm, https://github.com/ARM-software/devlib/pull/677 is filed to address your comments except open questions here.
Commits: