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! Willy
