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: Yury Norov <ynorov at caviumnetworks dot com>
- To: 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>, <adhemerval dot zanella at linaro dot org>, Yury Norov <yury dot norov at gmail dot com>
- Date: Tue, 28 Jun 2016 22:08:19 +0300
- Subject: Re: [PATCH 18/23] [AARCH64] ILP32: support stat syscall family
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp dot mailfrom=Yuri dot Norov at caviumnetworks dot com;
- 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>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
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?
> 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.
Yury