-
Notifications
You must be signed in to change notification settings - Fork 230
labgrid/qemudriver: tie QEMU and QMP monitor start/stop to on_activate()/on_deactivate() #1771
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
labgrid/qemudriver: tie QEMU and QMP monitor start/stop to on_activate()/on_deactivate() #1771
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1771 +/- ##
======================================
Coverage 45.2% 45.2%
======================================
Files 172 172
Lines 13569 13570 +1
======================================
+ Hits 6136 6140 +4
+ Misses 7433 7430 -3
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
|
Thanks for addressing this, @Bastian-Krause ! Seems indeed more adherent to the common design/usage patterns. I'll give it a closer look as soon as time permits. |
Since `qemu_version_mock` is required for all tests using `qemu_mock`, move its functionality into `qemu_mock`. Since `qemu_driver` will fixture will soon need `qemu_mock` always, add it as its dependency now, thus minimizing the direct fixtures required by the tests. Signed-off-by: Bastian Krause <[email protected]>
…e()/on_deactivate() Until now the QEMU process and QMP monitor start was tied to the on()/off() methods. This feels unnatural, preventing the user from interacting with the QEMU process via monitor commands before the emulation starts and meant starting a new process on each power cycle. Rework the driver to start QEMU and the QMP monitor in on_activate(), allowing interaction via monitor_command after activation. The on() and off() methods interact only via QMP now. All methods relying on a started QEMU and QMP monitor instance are decorated with @Driver.check_active now. The atexit handling is no longer required since the target's atexit handler already calls the driver's on_deactivate(). Signed-off-by: Joschka Seydell <[email protected]> Signed-off-by: Bastian Krause <[email protected]>
Now that the QEMU invocation is not only prepared, but also started in on_activate(), there is no need to keep the command around. Turn it into a local variable instead. Signed-off-by: Bastian Krause <[email protected]>
227eb60 to
b9b4489
Compare
|
Rebased on latest master. |
Description
Until now the QEMU process and QMP monitor start was tied to the
on()/off()methods. This feels unnatural, preventing the user from interacting with the QEMU process via monitor commands before the emulation starts and meant starting a new process on each power cycle.Rework the driver to start QEMU and the QMP monitor in on_activate(), allowing interaction via
monitor_command()after activation. Theon()andoff()methods interact only via QMP now.All methods relying on a started QEMU and QMP monitor instance are decorated with
@Driver.check_activenow.The atexit handling is no longer required since the target's atexit handler already calls the driver's
on_deactivate().While at it, restructure the QEMU mock fixtures in the QEMUDriver tests.
Checklist
Alternative to one aspect of #1753