This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 18/23] [AARCH64] ILP32: support stat syscall family
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Yury Norov <ynorov at caviumnetworks dot com>, Joseph Myers <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org, linux-kernel at vger dot kernel dot org, arnd at arndb dot de, catalin dot marinas at arm dot com, marcus dot shawcroft at arm dot com, philb at gnu dot org, davem at davemloft dot net, szabolcs dot nagy at arm dot com, maxim dot kuvyrkov at linaro dot org, pinskia at gmail dot com, bamvor dot zhangjian at huawei dot com, schwab at suse dot de, fweimer at redhat dot com, Prasun dot Kapoor at cavium dot com, cmetcalf at mellanox dot com, hjl dot tools at gmail dot com, Yury Norov <yury dot norov at gmail dot com>
- Date: Tue, 28 Jun 2016 17:41:55 -0300
- Subject: Re: [PATCH 18/23] [AARCH64] ILP32: support stat syscall family
- Authentication-results: sourceware.org; auth=none
- References: <1467131978-669-1-git-send-email-ynorov at caviumnetworks dot com> <1467131978-669-19-git-send-email-ynorov at caviumnetworks dot com> <alpine dot DEB dot 2 dot 20 dot 1606281713400 dot 25214 at digraph dot polyomino dot org dot uk> <20160628185102 dot GA2592 at yury-N73SV>
On 28/06/2016 16:08, Yury Norov wrote:
> On Tue, Jun 28, 2016 at 05:15:13PM +0000, Joseph Myers wrote:
>> <https://sourceware.org/ml/libc-alpha/2016-06/msg00791.html> still
>> applies. Unify implementations instead of proliferating variants.
>
> I think on it. I don't see simple way to unify it right now. And I
> plan to take a vacation in next two weeks, so I'd like to share my
> progress to community (mostly for kernel), as this series has some
> LTP tests fixed, and this is important for us.
>
> What you talk about sounds unclear to me. If you mean to unify with
> one of existing ports, it looks unnecessary, as ilp32 will end up with
> RISC-V anyway. If you mean to use RISC-V, it's not ready yet. I was
> thinking that when they will finish, they simply switch this port to
> their code. Am I too optimistic?
The idea is to avoid the proliferation of multiple implementation of
same function over multiple files. This have the advantage to make
easy for new ports to add such functionality and simplify the code
base. Take fstatfs{64} for instance:
$ find . -iname fstatfs*
./sysdeps/mach/hurd/fstatfs.c
./sysdeps/mach/hurd/fstatfs64.c
./sysdeps/unix/sysv/linux/generic/wordsize-32/fstatfs.c
./sysdeps/unix/sysv/linux/alpha/fstatfs64.c
./sysdeps/unix/sysv/linux/fstatfs64.c
./sysdeps/unix/sysv/linux/wordsize-64/fstatfs64.c
./sysdeps/unix/sysv/linux/mips/mips64/n64/fstatfs64.c
./io/fstatfs.c
./io/fstatfs64.c
The 'io' is the default one which is just a stub that return ENOSYS.
For Linux ideally we should aim to have just one implementation that
cover all the architectures/kernel limitation (the same idea I am
pushing with some consolidation patches).
It might be outside the scope of the port enablement, but it is usually
the opportunity to the refactor on such code. And for such functions
it might require some work for some architecture idiosyncrasies (such
as alpha not providing fstat64), but I think it quite doable.
>
>> Also, much of the formatting is way off the GNU Coding Standards (e.g.
>> indentation that's not two-column, "{" not on a line by itself), and
>> you're missing descriptions as first lines of many new files.
>
> Is there glibc analogue for kernel scripts/checkpatch.pl? If yes,
> please point me out, and I'll briefly fix all issues. If no please be
> patient to whitespace rules violations. I completely understand the
> importance of following the coding rules, but now I am little limited
> in time and prefer to fix real bugs first, and then read that document
> carefully and check all the mess I introduced.
Also keep in mind to remove the 'Contributed by ...' presented in some
files.
>
> Yury
>