On 2/25/20 5:02 PM, Willy Tarreau wrote:

On Tue, Feb 25, 2020 at 10:14:40AM +0300, Denis Efremov wrote:

quoted

On 2/25/20 6:45 AM, Willy Tarreau wrote:

quoted

On Tue, Feb 25, 2020 at 02:13:42AM +0300, Denis Efremov wrote:

quoted

On 2/25/20 12:53 AM, Linus Torvalds wrote:

quoted

So I'd like to see that second step that does the

    -static int fdc;                 /* current fdc */
    +static int current_fdc;

change.

We already call the global 'drive' variable 'current_drive', so it
really is 'fdc' that is misnamed and ambiguous because it then has two
different cases: the global 'fdc' and then the various shadowing local
'fdc' variables (or function arguments).

Mind adding that too? Slightly less automatic, I agree, because then
you really do have to disambiguate between the "is this the shadowed
use of a local 'fdc'" case or the "this is the global 'fdc' use" case.

I definitely agree. I first wanted to be sure the patches were acceptable
as a principle, but disambiguating the variables is easy to do now.

Ok, I don't want to break in the middle of your changes in this case.

So I started this and discovered the nice joke you were telling me
about regarding FD_IOPORT which references fdc. Then the address
registers FD_STATUS, FD_DATA, FD_DOR, FD_DIR, FD_DCR which are
based on FD_IOPORT also depend on it.

These ones are used by fd_outb() which is arch-dependent, so if we
want to pass a third argument we have to change them all and make sure
not to break them too much.

In addition the FD_* macros defined above are used by x86, and FD_DOR is
also used by arm while all other archs hard-code all the values. ARM also
uses floppy_selects[fdc] and new_dor... I'm starting to feel the trap here!
I also feel a bit concerned that these are exported in uapi with a hard-coded
0x3f0 base address. I'm just not sure how portable all of this is in
the end :-/

Now I'm wondering, how far should we go and how much is it acceptable to
change ? I'd rather not have "#define fdc current_fdc" just so that it
builds, but on the other hand this problem clearly outlights the roots
of the issue, which lies in "fdc" being silently accessed by macros with
nobody noticing!

I think that for the first attempt changing will be enough:
-static int fdc;                        /* current fdc */
+static int current_fdc;                        /* current fdc */
and
-#define FD_IOPORT fdc_state[fdc].address
+#define FD_IOPORT fdc_state[current_fdc].address
and for fd_setdor in ./arch/arm/include/asm/floppy.h

This already will require to at least test the building on x86,
arm, sparc arches (maybe more).

Just need to leave a note in the commit why it's not easy to
change FD_IOPORT in this case.

I think that small-step and observable patches are the best option
when we change floppy driver.

As for now, I can see that only floppy.c includes fdreg.h file
with define FDPATCHES. If it's true then #define FD_IOPORT 0x3f0 
branch is never used and we can try to fix remaining FD_* macro
in the next round.

Denis