[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH v4 00/12] fdc: fix 2.88mb floppy diskette suppor
From: |
Roman Kagan |
Subject: |
Re: [Qemu-block] [PATCH v4 00/12] fdc: fix 2.88mb floppy diskette support |
Date: |
Thu, 21 Jan 2016 18:37:08 +0300 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Thu, Jan 21, 2016 at 09:59:09AM -0500, John Snow wrote:
> > Now that is a bit trickier: the currently submitted code queries the
> > floppy properties at SSDT build time, and sticks static objects into
> > AML; if that really needs updating at runtime it'll require certain
> > refactoring.
> >
> > That said I'm not certain what exactly has to be done here. Physical
> > machines do not have their floppy drives changable at runtime, do they?
> > So the OSes should be fine assuming that the drive stays the same, and
> > it's only the diskette that can change. I'd guess that the OS driver
> > should do the necessary revalidation on its own, without ACPI
> > assistance; I'll give it a try when I have some time.
> >
> > But again, as you said, people are mainly interested in floppies to
> > bootstrap a Windows installation on virtio disks, so support of floppy
> > geometry update at runtime is non-critical for most users.
>
> I'm a little confused here. I am not proposing the ability to change a
> floppy drive type at runtime, just the ability to insert different kinds
> of diskettes, which does happen in the real world.
>
> e.g. a 2.88MB capable floppy drive that can read either 1.44MB or 2.88MB
> types.
That's right; the question WRT ACPI is whether the Windows driver
expects the drive parameters or the currently inserted diskette
parameters in the ACPI object; I guess the former, so we should be OK
with that data generated once at startup.
Roman.
- Re: [Qemu-block] [Qemu-devel] [PATCH v4 10/12] fdc: rework pick_geometry, (continued)