Re: [Qemu-devel] How to correctly use more than 2 floppy drives?

[John Snow <jsnow@redhat.com>]

On 4/9/19 7:38 AM, Philippe Mathieu-Daudé wrote:
> On 4/8/19 9:30 PM, John Snow wrote:
>> On 4/8/19 1:38 AM, Markus Armbruster wrote:
>>> Hervé Poussineau <hpoussin@reactos.org> writes:
>>>
>>>> Le 05/04/2019 à 12:29, Philippe Mathieu-Daudé a écrit :
>>>>> Hi,
>>>>>
>>>>> I am trying to understand the possible values for the MAX_FD variable
>>>>> used by the floppy controller model (hw/block/fdc.c).
> 
>> Out of curiosity, why?
> 
> Cleaning Super I/O chipset I figured some code uses arrays of 2 elements
> while other use MAX_FD. If we want to have a build-configurable MAX_FD
> we can't simply replace "2" -> "MAX_FD" to clean the codebase, we need
> to correct various places, and fix migration.
> If we agree that MAX_FD is strictly 2, then we can clean the codebase
> and remove the MAX_FD != 2 cases (point 3/ below).

OK! I just get nervous when people start poking around floppy disks :)

It's "maintained" but really I just keep it on life support. If anyone
were to claim responsibility for it I would happily let them. As you can
guess, floppy disks are not a huge business priority for my employer and
I am not personally passionate about them, so...

I just keep it alive out of kindness and, for a time, support for
loading virtio drivers on Windows XP VMs, which is a use case that Red
Hat doesn't care about too much anymore.

>>
>> I think I'd rather have MAX_FD set to 2 and a cleaner codebase than a
>> half-working implementation for 4.
>>
>> Or, does it actually work with four? I think if Hervé wants to preserve
>> this feature it should be formalized as a device property and made to
>> work with migration ... or I am content to remove it.
> 
> I understand Hervé doesn't want to preserve his attempt ("no emulated
> board took advantage of it"), and the work is safe in the git history if
> someone want to restore it (in a way that doesn't break migration).
> 
> Since we all seems to agree, I prepared a series to remove it and will
> send it soon (although there is no rush).
> 
> Thanks,
> 
> Phil.
> 

Sounds good, thank you!