Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Reply-To: efremov@linux.com
Subject: Re: [PATCH 01/10] floppy: cleanup: expand macro FDCS
To:     Willy Tarreau <w@1wt.eu>
Cc:     Jens Axboe <axboe@kernel.dk>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-block <linux-block@vger.kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>
References: <20200224212352.8640-1-w@1wt.eu> <20200224212352.8640-2-w@1wt.eu>
 <CAHk-=wi4R_nPdE4OuNW9daKFD4FpV74PkG4USHqub+nuvOWYFg@mail.gmail.com>
 <28e72058-021d-6de0-477e-6038a10d96da@linux.com>
 <20200225034529.GA8908@1wt.eu>
 <c181b184-1785-b221-76fa-4313bbada09d@linux.com>
 <20200225140207.GA31782@1wt.eu>
From:   Denis Efremov <efremov@linux.com>
Message-ID: <10bc7df1-7a80-a05a-3434-ed0d668d0c6c@linux.com>
Date:   Tue, 25 Feb 2020 18:22:47 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <20200225140207.GA31782@1wt.eu>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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