On 2/25/20 5:02 PM, Willy Tarreau wrote: > On Tue, Feb 25, 2020 at 10:14:40AM +0300, Denis Efremov wrote: >> >> >> On 2/25/20 6:45 AM, Willy Tarreau wrote: >>> On Tue, Feb 25, 2020 at 02:13:42AM +0300, Denis Efremov wrote: >>>> On 2/25/20 12:53 AM, Linus Torvalds wrote: >>>>> 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
