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

[Philippe Mathieu-Daudé]

On 4/8/19 9:30 PM, John Snow wrote:
> On 4/8/19 1:38 AM, Markus Armbruster wrote:
>> Hervé Poussineau <address@hidden> 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).

>>>> Looking at git history:
>>>>
>>>> - 2004-01-05 7138fcfbf7dd + 8977f3c107ef (Jocelyn Mayer):
>>>>    FDC introduced with "#define MAX_FD 2"
>>>>
>>>> - 2008-04-29 78ae820cfeb0 (Hervé Poussineau):
>>>>    Supports up to 4 floppy drives if MAX_FD is set to 4
>>>>    Migration stream knows about runtime value of MAX_FD
>>>>
>>>> - 2009-09-10 d7a6c2703577 (Juan Quintela):
>>>>    FDC vmstate-ified
>>>>    Migration stream use compile time value of MAX_FD
>>>>
>>>> Since 7138fcfbf7dd MAX_FD has always been defined as 2.
>>>>
>>>> Since d7a6c2703577 MAX_FD can not be different than 2 without breaking
>>>> migration.
>>>>
>>>> If I understand correctly migration, first we should change in
>>>> vmstate_fdc the user-definable MAX_FD by a constant 2 value.
>>>>
>>>> Then to be able to use >2 floppy disks I have to modify the the
>>>> vmstate.version_id, and
>>>>
>>>> 1/ add a new field in the vmstate_fdc containing the number of drives
>>>> and add code to check >2 and adapt
>>>>
>>>> or
>>>>
>>>> 2/ change MAX_FD to 4 for all the codebase, adding some code to migrate
>>>> to older FDC with only 2 disks...
>>>>
>>>> Another option I don't like is:
>>>>
>>>> 3/ get ride of MAX_FD != 2 and clean the codebase...
>>>>
>>>> $ git grep '#if MAX_FD'
>>>> hw/block/fdc.c:744:#if MAX_FD == 4
>>>> hw/block/fdc.c:758:#if MAX_FD == 4
>>>> hw/block/fdc.c:1317:#if MAX_FD == 4
>>>> hw/block/fdc.c:1340:#if MAX_FD == 4
>>>> hw/block/fdc.c:2041:#if MAX_FD == 4
>>>> hw/block/fdc.c:2079:#if MAX_FD == 4
>>>> hw/block/fdc.c:2104:#if MAX_FD == 4
>>>>
>>>> Hervé, what board are/were you using with 4 floppy drives?
>>>
>>> That was only an attempt to support 4 drives in code, as controller was 
>>> able to do it.
>>> However, no emulated board took advantage of it, so that's why it kind-of 
>>> regressed.
>>>
>>> Feel free to choose the solution you prefer.
>>
>> Since no user has appeared since 2008, it feels safe enough to assume
>> that none will appear going forward.  I lean towards your "3/ get ride
>> of MAX_FD != 2 and clean the codebase..."  Explain in a comment that we
>> emulate only a 2-drive floppy controller, not the genuine IBM PC 4-drive
>> floppy controller.
>>
> 
> 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.