RFS and 2038
joel at rtems.org
Thu May 27 12:04:48 UTC 2021
On Wed, May 26, 2021, 9:58 PM Chris Johns <chrisj at rtems.org> wrote:
> On 1/5/21 6:19 am, Joel Sherrill wrote:
> > Hi
> > Ryan has been working to add support for the new (not obsolete)
> > granularity variants of utime. In changing the utime_h file system
> handler to
> > utimens_h and propagating the changes, Ryan tripped across this.
> > rtems/rfs/rtems-rfs-inode.h:typedef uint32_t rtems_rfs_time;
> > Our first inclination was to change this to time_t but I remembered that
> > was 64-bits and that changing this could ripple to on-media structures.
> > Ignoring that there is no sub-second granularity on the utime family of
> > timestamps for the RFS (and other filesystems), how can this year 2038
> > be addressed?
> > I am pretty sure a ticket is needed but I wanted to discuss this and
> > the scope.
> > We may also have similar issues in other file systems that we didn't
> Did this get resolved?
No. The API additions required a minor header file change in newlib. I
bumped the RSB for this. There is a patch for RTEMS, libbsd, and legacy net
to switch the filesystem utime handler to the nanosecond signature.
I've been letting the RSB patch be committed a bit before pushing the
others since it is a break.
> (still under his rock)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel