Arnd and I had a discussion about how to proceed here.
We don't think anybody really is wanting a big patch touching 50 fs here.
We are evaluating a couple of approaches that don't do this.
I will post an update next week
On Wed, Jan 20, 2016 at 3:17 PM, Arnd Bergmann wrote:
> On Thursday 21
Arnd and I had a discussion about how to proceed here.
We don't think anybody really is wanting a big patch touching 50 fs here.
We are evaluating a couple of approaches that don't do this.
I will post an update next week
On Wed, Jan 20, 2016 at 3:17 PM, Arnd Bergmann wrote:
>
On Thursday 21 January 2016 10:06:32 Dave Chinner wrote:
>
> IOWs, you're now finally suggesting doing the *simple conversion*
> I've been suggesting needs to be made *since the start* of this
> long, frustrating thread, except you *still want to abstract the
> timestamp unnecessarily*.
>
> For
On Tue, Jan 19, 2016 at 11:25:02PM +0100, Arnd Bergmann wrote:
> On Wednesday 20 January 2016 07:49:46 Dave Chinner wrote:
> > You're doing it wrong. fat_time_fat2unix() still gets passed
> > >i_mtime, and the function prototype is changed to a
> > timespec64. *Nothing else needs to change*,
On Tue, Jan 19, 2016 at 9:12 PM, Deepa Dinamani wrote:
>
> On Tue, Jan 19, 2016 at 2:25 PM, Arnd Bergmann wrote:
>> On Wednesday 20 January 2016 07:49:46 Dave Chinner wrote:
>>> On Mon, Jan 18, 2016 at 09:27:13PM -0800, Deepa Dinamani wrote:
>>> > On Mon, Jan 18, 2016 at 5:38 PM, Dave Chinner
On Tue, Jan 19, 2016 at 9:12 PM, Deepa Dinamani wrote:
>
> On Tue, Jan 19, 2016 at 2:25 PM, Arnd Bergmann wrote:
>> On Wednesday 20 January 2016 07:49:46 Dave Chinner wrote:
>>> On Mon, Jan 18, 2016 at 09:27:13PM -0800, Deepa Dinamani wrote:
>>> > On Mon,
On Tue, Jan 19, 2016 at 11:25:02PM +0100, Arnd Bergmann wrote:
> On Wednesday 20 January 2016 07:49:46 Dave Chinner wrote:
> > You're doing it wrong. fat_time_fat2unix() still gets passed
> > >i_mtime, and the function prototype is changed to a
> > timespec64. *Nothing else needs to change*,
On Thursday 21 January 2016 10:06:32 Dave Chinner wrote:
>
> IOWs, you're now finally suggesting doing the *simple conversion*
> I've been suggesting needs to be made *since the start* of this
> long, frustrating thread, except you *still want to abstract the
> timestamp unnecessarily*.
>
> For
The current representation of inode times in struct inode, struct iattr,
and struct kstat use struct timespec. timespec is not y2038 safe.
Use scalar data types (seconds and nanoseconds stored separately) to
represent timestamps in struct inode in order to maintain same size for
times across 32
The current representation of inode times in struct inode, struct iattr,
and struct kstat use struct timespec. timespec is not y2038 safe.
Use scalar data types (seconds and nanoseconds stored separately) to
represent timestamps in struct inode in order to maintain same size for
times across 32
10 matches
Mail list logo