Re: [PATCH 18/23] [AARCH64] ILP32: support stat syscall family

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

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
>