Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1433154 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 18/23] [AARCH64] ILP32: support stat syscall family Joseph Myers <joseph@codesourcery.com> - 2016-06-28 19:20 +0200
    Re: [PATCH 18/23] [AARCH64] ILP32: support stat syscall family Adhemerval Zanella <adhemerval.zanella@linaro.org> - 2016-06-28 22:50 +0200
    Re: [PATCH 18/23] [AARCH64] ILP32: support stat syscall family Joseph Myers <joseph@codesourcery.com> - 2016-06-28 22:50 +0200

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

<https://sourceware.org/ml/libc-alpha/2016-06/msg00791.html> still 
applies.  Unify implementations instead of proliferating variants.

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.

-- 
Joseph S. Myers
joseph@codesourcery.com

[toc] | [next] | [standalone]

#1433289

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
> 

[toc] | [prev] | [next] | [standalone]

#1433291

On Tue, 28 Jun 2016, Yury Norov wrote:

> 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?

I mean unify in sysdeps/unix/sysv/linux (or .../generic if inappropriate 
for the main sysdeps/unix/sysv/linux), for all architectures, both 
existing and new, with conditionals based on logical features of the 
architectures.  If any architecture has its own implementation, it should 
only be old architectures with their special peculiarities.

> 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

I'm not aware of an analogue, although GCC's contrib/check_GNU_style.sh 
may well be helpful for some issues.

-- 
Joseph S. Myers
joseph@codesourcery.com

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web