On Wed, May 26, 2021, 9:58 PM Chris Johns <chr...@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) > nanosecond > > 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 > time_t > > 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 > problem > > be addressed? > > > > I am pretty sure a ticket is needed but I wanted to discuss this and > understand > > the scope. > > > > We may also have similar issues in other file systems that we didn't > spot. > > 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. > Chris > (still under his rock) >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
