From: Thomas Huth <thuth@redhat.com>
To: John Snow <jsnow@redhat.com>,
qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
qemu-block@nongnu.org, David Hildenbrand <david@redhat.com>,
QEMU Trivial <qemu-trivial@nongnu.org>,
"Michael S. Tsirkin" <mst@redhat.com>,
Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [PATCH 2/4] hw/block/fdc: Remove the check_media_rate property
Date: Mon, 8 Feb 2021 08:05:44 +0100 [thread overview]
Message-ID: <3b57740e-ad39-3e56-6262-7994376f74a9@redhat.com> (raw)
In-Reply-To: <96906059-731d-1e48-5b60-98ed4df9c037@redhat.com>
On 05/02/2021 21.15, John Snow wrote:
> 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@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@redhat.com>
> Acked-by: John Snow <jsnow@redhat.com>
Thanks! ... since the first patch has already been merged through Michael's
tree, could you then please take this patch here through your floppy / block
branch, John? Or maybe it could also go via qemu-trivial?
Thomas
next prev parent reply other threads:[~2021-02-08 11:54 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-03 17:18 [PATCH 0/4] Remove the deprecated pc-1.x machine types and related stuff Thomas Huth
2021-02-03 17:18 ` [PATCH 1/4] hw/i386: Remove the deprecated pc-1.x machine types Thomas Huth
2021-02-03 17:37 ` Daniel P. Berrangé
2021-02-03 17:18 ` [PATCH 2/4] hw/block/fdc: Remove the check_media_rate property Thomas Huth
2021-02-05 0:40 ` John Snow
2021-02-05 6:37 ` Thomas Huth
2021-02-05 20:15 ` John Snow
2021-02-08 7:05 ` Thomas Huth [this message]
2021-02-13 22:41 ` Laurent Vivier
2021-02-15 18:11 ` John Snow
2021-02-03 17:18 ` [PATCH 3/4] hw/virtio/virtio-balloon: Remove the "class" property Thomas Huth
2021-02-03 19:42 ` David Hildenbrand
2021-02-03 17:18 ` [PATCH 4/4] hw/usb/bus: Remove the "full-path" property Thomas Huth
2021-02-04 8:36 ` Gerd Hoffmann
2021-02-04 15:51 ` Thomas Huth
2021-02-05 9:09 ` Gerd Hoffmann
2021-02-05 11:00 ` [PATCH 0/4] Remove the deprecated pc-1.x machine types and related stuff Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3b57740e-ad39-3e56-6262-7994376f74a9@redhat.com \
--to=thuth@redhat.com \
--cc=david@redhat.com \
--cc=ehabkost@redhat.com \
--cc=jsnow@redhat.com \
--cc=kraxel@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-trivial@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).