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.

Reply via email to