Re: [PATCH 2/4] hw/block/fdc: Remove the check_media_rate property

[Thomas Huth]

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@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?

 Thomas