[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK8P3a2bSsMDxUJfrEP-ybENL0czXrNwZCb2kGA46E42xAtu=g@mail.gmail.com>
Date: Thu, 19 Jul 2018 10:53:24 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Joseph Myers <joseph@...esourcery.com>
Cc: Christoph Hellwig <hch@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
y2038 Mailman List <y2038@...ts.linaro.org>,
Linux API <linux-api@...r.kernel.org>,
linux-arch <linux-arch@...r.kernel.org>,
GNU C Library <libc-alpha@...rceware.org>,
Albert ARIBAUD <albert.aribaud@...ev.fr>,
Networking <netdev@...r.kernel.org>,
Al Viro <viro@...iv.linux.org.uk>,
Peter Zijlstra <peterz@...radead.org>,
Darren Hart <dvhart@...radead.org>,
"Eric W . Biederman" <ebiederm@...ssion.com>,
Dominik Brodowski <linux@...inikbrodowski.net>
Subject: Re: [PATCH v2 02/17] y2038: Remove newstat family from default
syscall set
On Wed, Jul 18, 2018 at 10:15 PM, Joseph Myers <joseph@...esourcery.com> wrote:
> On Tue, 17 Jul 2018, Arnd Bergmann wrote:
>
>> That would definitely help. See below for the stat implementation
>> I did in my musl libc prototype based on statx(). It passes the
>> LTP syscall tests, but that doesn't mean all the corner cases
>> are correct.
>
> Well, you definitely need explicit timestamp conversions on the result of
> statx to be usable in struct stat when userspace "long" is 64-bit, for BE
> because otherwise the integer nanoseconds will be in the wrong place for
> struct timespec, and for LE if the "__reserved is held in case we need a
> yet finer resolution." might start being returned as nonzero (for integer
> attoseconds, I suppose) in future.
Right. The musl implementation I sent did that by simply copying each
field we care about from the statx structure into the stat structure
individually. This is the more or less the same thing that the kernel
does to implement stat() as well.
Arnd
Powered by blists - more mailing lists