[PATCH 2/4] hw/block/fdc: Remove the check_media_rate property
John Snow
jsnow at redhat.com
Fri Feb 5 20:15:56 UTC 2021
On 2/5/21 1:37 AM, Thomas Huth wrote:
> On 05/02/2021 01.40, John Snow wrote:
>> On 2/3/21 12:18 PM, Thomas Huth wrote:
>>> This was only required for the pc-1.0 and earlier machine types.
>>> Now that these have been removed, we can also drop the corresponding
>>> code from the FDC device.
>>>
>>> Signed-off-by: Thomas Huth <thuth at redhat.com>
>>> ---
>>> hw/block/fdc.c | 17 ++---------------
>>> tests/qemu-iotests/172.out | 35 -----------------------------------
>>> 2 files changed, 2 insertions(+), 50 deletions(-)
>>>
>>> diff --git a/hw/block/fdc.c b/hw/block/fdc.c
>>> index 292ea87805..198940e737 100644
>>> --- a/hw/block/fdc.c
>>> +++ b/hw/block/fdc.c
>>> @@ -874,7 +874,6 @@ struct FDCtrl {
>>> FloppyDriveType type;
>>> } qdev_for_drives[MAX_FD];
>>> int reset_sensei;
>>> - uint32_t check_media_rate;
>>
>> I am a bit of a dunce when it comes to the compatibility properties...
>> does this mess with the migration format?
>>
>> I guess it doesn't, since it's not in the VMSTATE declaration.
>>
>> Hmmmm, alright.
>
> I think that should be fine, yes.
>
>>> FloppyDriveType fallback; /* type=auto failure fallback */
>>> /* Timers state */
>>> uint8_t timer0;
>>> @@ -1021,18 +1020,10 @@ static const VMStateDescription
>>> vmstate_fdrive_media_changed = {
>>> }
>>> };
>>> -static bool fdrive_media_rate_needed(void *opaque)
>>> -{
>>> - FDrive *drive = opaque;
>>> -
>>> - return drive->fdctrl->check_media_rate;
>>> -}
>>> -
>>> static const VMStateDescription vmstate_fdrive_media_rate = {
>>> .name = "fdrive/media_rate",
>>> .version_id = 1,
>>> .minimum_version_id = 1,
>>> - .needed = fdrive_media_rate_needed,
>>> .fields = (VMStateField[]) {
>>> VMSTATE_UINT8(media_rate, FDrive),
>>> VMSTATE_END_OF_LIST()
>>> @@ -1689,8 +1680,7 @@ static void fdctrl_start_transfer(FDCtrl
>>> *fdctrl, int direction)
>>> /* Check the data rate. If the programmed data rate does not match
>>> * the currently inserted medium, the operation has to fail. */
>>> - if (fdctrl->check_media_rate &&
>>> - (fdctrl->dsr & FD_DSR_DRATEMASK) != cur_drv->media_rate) {
>>> + if ((fdctrl->dsr & FD_DSR_DRATEMASK) != cur_drv->media_rate) {
>>> FLOPPY_DPRINTF("data rate mismatch (fdc=%d, media=%d)\n",
>>> fdctrl->dsr & FD_DSR_DRATEMASK,
>>> cur_drv->media_rate);
>>> fdctrl_stop_transfer(fdctrl, FD_SR0_ABNTERM, FD_SR1_MA, 0x00);
>>> @@ -2489,8 +2479,7 @@ static void fdctrl_result_timer(void *opaque)
>>> cur_drv->sect = (cur_drv->sect % cur_drv->last_sect) + 1;
>>> }
>>> /* READ_ID can't automatically succeed! */
>>> - if (fdctrl->check_media_rate &&
>>> - (fdctrl->dsr & FD_DSR_DRATEMASK) != cur_drv->media_rate) {
>>> + if ((fdctrl->dsr & FD_DSR_DRATEMASK) != cur_drv->media_rate) {
>>> FLOPPY_DPRINTF("read id rate mismatch (fdc=%d, media=%d)\n",
>>> fdctrl->dsr & FD_DSR_DRATEMASK,
>>> cur_drv->media_rate);
>>> fdctrl_stop_transfer(fdctrl, FD_SR0_ABNTERM, FD_SR1_MA, 0x00);
>>> @@ -2895,8 +2884,6 @@ static Property isa_fdc_properties[] = {
>>> DEFINE_PROP_UINT32("dma", FDCtrlISABus, dma, 2),
>>> DEFINE_PROP_DRIVE("driveA", FDCtrlISABus,
>>> state.qdev_for_drives[0].blk),
>>> DEFINE_PROP_DRIVE("driveB", FDCtrlISABus,
>>> state.qdev_for_drives[1].blk),
>>> - DEFINE_PROP_BIT("check_media_rate", FDCtrlISABus,
>>> state.check_media_rate,
>>> - 0, true),
>>
>> Could you theoretically set this via QOM commands in QMP, and claim
>> that this is a break in behavior?
>>
>> Though, it's ENTIRELY undocumented, so ... it's probably fine, I
>> think. Probably. (Please soothe my troubled mind.)
>
> A user actually could mess with this property even on the command line,
> e.g. by using:
>
> qemu-system-x86_64 -global isa-fdc.check_media_rate=false
>
> ... but, as you said, it's completely undocumented, the property is
> really just there for the internal use of machine type compatibility.
> We've done such clean-ups in the past already, see e.g.
> c6026998eef382d7ad76 or 2a4dbaf1c0db2453ab78f, so I think this should be
> fine. But if you disagree, I could replace this by a patch that adds
> this property to the list of deprecated features instead, so we could at
> least remove it after it has been deprecated for two releases?
>
I don't think it's necessary, personally -- just wanted to make sure I
knew the exact stakes here.
Reviewed-by: John Snow <jsnow at redhat.com>
Acked-by: John Snow <jsnow at redhat.com>
More information about the libvir-list
mailing list