[RFC][PATCH 00/12] Enhanced file stat system call

classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 01/12] Ext4: Fix extended timestamp encoding and decoding

Theodore Ts'o
On Sun, Nov 29, 2015 at 10:30:39PM +0100, Arnd Bergmann wrote:
> The other large missing piece is the system call implementation. I have
> posted a series earlier this year before my parental leave, and it's
> currently lacking review from libc folks, and blocked on me to update
> the series and post it again.

I assume that this also means there hasn't been much thought about
userspace support above libc?  i.e., how to take a 64-bit time64_t (or
changing the size of time_t) and translating that to a string using
some kind of version of ctime() and asctime(), and how to parse a
post-2038 date string and turning it into a 64-bit time_t on a 32-bit
platform?

The reason why I'm asking is because I'm thinking about how to add the
appropriate regression test support to e2fsprogs for 32-bit platforms.
I'm probably going to just skip the tests on architectures where
sizeof(time_t) == 4 for now, since with a 32-bit time_t adding support
for post-2038 in a e2fsprogs-specific way is (a) something I don't
have time for, and (b) probably a waste of time since presumably we
will either need to have a more general solution, or simply decide to
give up on 32-bit platforms by 2038....

Cheers,

                        - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 01/12] Ext4: Fix extended timestamp encoding and decoding

Arnd Bergmann
On Monday 30 November 2015 09:16:05 Theodore Ts'o wrote:

> On Sun, Nov 29, 2015 at 10:30:39PM +0100, Arnd Bergmann wrote:
> > The other large missing piece is the system call implementation. I have
> > posted a series earlier this year before my parental leave, and it's
> > currently lacking review from libc folks, and blocked on me to update
> > the series and post it again.
>
> I assume that this also means there hasn't been much thought about
> userspace support above libc?  i.e., how to take a 64-bit time64_t (or
> changing the size of time_t) and translating that to a string using
> some kind of version of ctime() and asctime(), and how to parse a
> post-2038 date string and turning it into a 64-bit time_t on a 32-bit
> platform?
>
> The reason why I'm asking is because I'm thinking about how to add the
> appropriate regression test support to e2fsprogs for 32-bit platforms.
> I'm probably going to just skip the tests on architectures where
> sizeof(time_t) == 4 for now, since with a 32-bit time_t adding support
> for post-2038 in a e2fsprogs-specific way is (a) something I don't
> have time for, and (b) probably a waste of time since presumably we
> will either need to have a more general solution, or simply decide to
> give up on 32-bit platforms by 2038....

We are definitely going to be using 32-bit embedded platforms in 2038,
but we won't be using a 32-bit time_t then, so basing the check on
sizeof(time_t) sounds reasonable. I assume most generic distros will
stay with 32-bit time_t for compatibility reasons and just not give
long term support for 32-bit architectures, while the embedded
distros will move over to 64-bit time_t, but on those you recompile
all user space for each product anyway.

The glibc functions should all work with a 64-bit time_t as they do
today on 64-bit architectures. There is an open discussion on how
you move to 64-bit time_t. With the current
glibc plan at https://sourceware.org/glibc/wiki/Y2038ProofnessDesign,
you will have to set -D_TIME_BITS=64 to enable it explicitly, but
I'd also like to see a way to build a glibc that defaults to that
and does not allow backwards compatibility, which is important for
folks that want to ship a system that has they can guarantee to
survive 2038.

        Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 01/12] Ext4: Fix extended timestamp encoding and decoding

Elmar Stellnberger
In reply to this post by Theodore Ts'o


On 30.11.2015 15:16, Theodore Ts'o wrote:

> On Sun, Nov 29, 2015 at 10:30:39PM +0100, Arnd Bergmann wrote:
>> The other large missing piece is the system call implementation. I have
>> posted a series earlier this year before my parental leave, and it's
>> currently lacking review from libc folks, and blocked on me to update
>> the series and post it again.
>
> I assume that this also means there hasn't been much thought about
> userspace support above libc?  i.e., how to take a 64-bit time64_t (or
> changing the size of time_t) and translating that to a string using
> some kind of version of ctime() and asctime(), and how to parse a
> post-2038 date string and turning it into a 64-bit time_t on a 32-bit
> platform?
>

   Arnd, I would just like to tell you how much I welcome your decision
for a new __kernel_time64_t!
   As a time[64]_t is basically well defined counting artificial seconds
since the epoch (1970-01-01 00:00) where every year divisible by four is
a leap year that is for the meanwhile already sufficient to make use of
your new type. I just think about the Mayan calendar application which I
have implemented last year (Though I have not brought it to a
publishable state yet). A single typedef should be sufficient to let it
make use of time64_t (it directly uses this type as well as long long
internally for its calculations rather than the glibc time format
functions).

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 03/12] statx: Add a system call to make enhanced file info available

Pavel Machek
In reply to this post by David Howells
Hi!

> ===============
> NEW SYSTEM CALL
> ===============
>
> The new system call is:
>
> int ret = statx(int dfd,
> const char *filename,
> unsigned int flags,
> unsigned int mask,
> struct statx *buffer);

Should this be called stat5, so that when new, even more improved stat
comes, it does not have to be called statxx?

> The dfd, filename and flags parameters indicate the file to query.  There
> is no equivalent of lstat() as that can be emulated with statx() by passing
> AT_SYMLINK_NOFOLLOW in flags.  There is also no equivalent of fstat() as
> that can be emulated by passing a NULL filename to statx() with the fd of
> interest in dfd.

Dunno. Of course you can multiplex everything.

But fstat() is really different operation to stat() -- tell me about
my file descriptor vs. tell me about this filename, and ptrace (and
some "security" solutions) might want to allow one but disallow the
second. I'd not group them together..

                                                                        Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 03/12] statx: Add a system call to make enhanced file info available

David Howells
Pavel Machek <[hidden email]> wrote:

> But fstat() is really different operation to stat() -- tell me about
> my file descriptor vs. tell me about this filename, and ptrace (and
> some "security" solutions) might want to allow one but disallow the
> second. I'd not group them together..

You can argue it either way.  I think Linus came down on the side of combining
them.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
123