On Sat, May 31, 2014 at 4:54 PM, Arnd Bergmann wrote:
> On Saturday 31 May 2014 10:39:02 Andreas Schwab wrote:
>> Geert Uytterhoeven writes:
>>
>> > Hi Arnd,
>> >
>> > On Fri, May 30, 2014 at 10:01 PM, Arnd Bergmann wrote:
>> >> + * The variant using bit fields is less efficient to access, but
>
Yes, s64/u32 or s64/s32.
On May 31, 2014 7:53:01 AM PDT, Arnd Bergmann wrote:
>On Saturday 31 May 2014 02:03:38 H. Peter Anvin wrote:
>> On 05/30/2014 01:01 PM, Arnd Bergmann wrote:
>> > +#ifdef CONFIG_NEW_INODE_TIME
>> > +/*
>> > + * This is the type we use internally in the kernel to represent
On Saturday 31 May 2014 10:39:02 Andreas Schwab wrote:
> Geert Uytterhoeven writes:
>
> > Hi Arnd,
> >
> > On Fri, May 30, 2014 at 10:01 PM, Arnd Bergmann wrote:
> >> + * The variant using bit fields is less efficient to access, but
> >> + * small and has a wider range as the 32-bit one, plus it
On Saturday 31 May 2014 02:03:38 H. Peter Anvin wrote:
> On 05/30/2014 01:01 PM, Arnd Bergmann wrote:
> > +#ifdef CONFIG_NEW_INODE_TIME
> > +/*
> > + * This is the type we use internally in the kernel to represent
> > + * absolute times in file system metadata.
> > + * This structure must not leak
Geert Uytterhoeven writes:
> "int" is signed, right? Or do you mean a bitfield needs an explicit "signed"
> keyword to be signed?
Yes, see 6.7.2#5.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something
Hi Andreas,
On Sat, May 31, 2014 at 10:39 AM, Andreas Schwab wrote:
> Geert Uytterhoeven writes:
>
>> Hi Arnd,
>>
>> On Fri, May 30, 2014 at 10:01 PM, Arnd Bergmann wrote:
>>> + * The variant using bit fields is less efficient to access, but
>>> + * small and has a wider range as the 32-bit one
On 05/30/2014 01:01 PM, Arnd Bergmann wrote:
> +#ifdef CONFIG_NEW_INODE_TIME
> +/*
> + * This is the type we use internally in the kernel to represent
> + * absolute times in file system metadata.
> + * This structure must not leak out to user space, and new interfaces
> + * should be using 64-bit
Geert Uytterhoeven writes:
> Hi Arnd,
>
> On Fri, May 30, 2014 at 10:01 PM, Arnd Bergmann wrote:
>> + * The variant using bit fields is less efficient to access, but
>> + * small and has a wider range as the 32-bit one, plus it keeps
>> + * the signedness of the original timespec.
>> + */
>> +st
Hi Arnd,
On Fri, May 30, 2014 at 10:01 PM, Arnd Bergmann wrote:
> + * The variant using bit fields is less efficient to access, but
> + * small and has a wider range as the 32-bit one, plus it keeps
> + * the signedness of the original timespec.
> + */
> +struct inode_time {
> + long long
As one part of the puzzle to solve the y2038 problem, this introduces
a new time type to be used for keeping inode timestamps (atime, ctime,
mtime) inside of the kernel.
Initially, this type is defined to 'struct timespec' to allow migrating
all file systems one by one, but the intention is to cha
10 matches
Mail list logo
