This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC v1 10/16] RISC-V: The ABI implementation for the 32-bit
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: libc-alpha at sourceware dot org
- Date: Mon, 24 Jun 2019 08:58:35 -0300
- Subject: Re: [RFC v1 10/16] RISC-V: The ABI implementation for the 32-bit
- References: <CAK8P3a0ofPn8EPSgOg36BXOOe3Jjdbw0euvak=+w9KJ-8h9_Yw@mail.gmail.com> <mhng-8aab6919-d6ad-44e0-9221-fda9b350785c@palmer-si-x1e> <CAK8P3a06HKtY7e0q70jVxYfS31mHV6EVd9TQYRO=i7n6xPhXMQ@mail.gmail.com>
On 24/06/2019 06:51, Arnd Bergmann wrote:
> On Mon, Jun 24, 2019 at 4:49 AM Palmer Dabbelt <palmer@sifive.com> wrote:
>>
>> On Sun, 23 Jun 2019 12:41:20 PDT (-0700), Arnd Bergmann wrote:
>>> On Sat, Jun 22, 2019 at 6:47 AM Alistair Francis
>>> <alistair.francis@wdc.com> wrote:
>>>
>>>> sysdeps/unix/sysv/linux/riscv/rv32/lockf64.c | 70 +++++++++++++++++++
>>>
>>> Why is this file architecture specific? It seems everything else just uses
>>> #include <sysdeps/unix/sysv/linux/i386/lockf64.c>
>>> Is your code different from that version?
>>
>> As part of the code review it was indicated that we shouldn't #include C files
>> but should instead duplicate them. At the time it was exactly the same, we
>> should scrutinize any differences as that was months ago.
>
> I would expect that you would want it to be consistent across architectures
> as well: so either replace all the other #include versions with direct copies,
> or move the file into a more generic location that avoids the #include if you
> can't add another one any more.
>
> Arnd
>
Since e442e40de5646e93bf31ace3e0c5159085a7259b glibc lock{64} is based on
fcntl{64}. And sysdeps/unix/sysv/linux/fcntl{64}.c should already call
__NR_fcntl64 for the required cases. So why do you need to add an arch
specific lock64 implementation here?