[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Semantics of DeviceState::realized and BlockDriverState
From: |
Anthony Liguori |
Subject: |
[Qemu-devel] Semantics of DeviceState::realized and BlockDriverState |
Date: |
Mon, 11 Jun 2012 17:05:03 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 |
Hi,
I wanted to start a central thread as this discussion is spread in two places
right now.
I think I'm becoming convinced that realized belongs in DeviceState and that
BlockDriverState does not have a realized equivalent.
To me, realized represents Vcc. When realized=true, the guest has power and is
active. When realized=false, the guest has lost power. The realize() event is
the rising edge of Vcc, unrealized() is the falling edge.
realize() should be used to take any actions that require all parameters to be
set that need to happen before the guest has power. This later clause is
extremely important. unrealize() should be used to unset anything setup in
realize().
The destructor being invoked does not imply that unrealize() has happened.
I think BlockDriverState wants two separate signals: an opened signal and an
attached signal.
With BDS, there are a few phases:
opened = false
attached = false
All properties can be set here and no side effects occur.
It is not valid to do a read/write request to a BDS in this state.
opened = true
attached = false
Properties that affect file opening (flags and filename) cannot be changed after
this point. Depending on the contents of the file, a backing_file property may
be created after opened = true. The backing_file that gets created does *not*
automatically have opened = true. A user explicitly needs to set that.
This behavior is necessary to allow overriding backing files.
It is not valid to do a read/write request to a BDS in this state.
opened = true
attached = true
This means that the device is in-use by something in QEMU. Requests may be in
flight as read/write requests are now allowed to be issued.
Most properties cannot be changed in this state (presumably).
opened = false
attached = true
Invalid state.
So there are three valid states and none of them map directly to the concept of
realized for devices.
I think this argues pretty clearly for realize() to not live in Object and
instead to allow base classes to implement whatever properties make sense to them.
Regard,
Anthony Liguori
- [Qemu-devel] Semantics of DeviceState::realized and BlockDriverState,
Anthony Liguori <=