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.
