<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 26, 2021, 9:58 PM Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank" rel="noreferrer">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 1/5/21 6:19 am, Joel Sherrill wrote:<br>
> Hi<br>
> <br>
> Ryan has been working to add support for the new (not obsolete) nanosecond<br>
> granularity variants of utime. In changing the utime_h file system handler to<br>
> utimens_h and propagating the changes, Ryan tripped across this.<br>
> <br>
> rtems/rfs/rtems-rfs-inode.h:typedef uint32_t rtems_rfs_time;<br>
> <br>
> Our first inclination was to change this to time_t but I remembered that time_t<br>
> was 64-bits and that changing this could ripple to on-media structures. <br>
> <br>
> Ignoring that there is no sub-second granularity on the utime family of<br>
> timestamps for the RFS (and other filesystems), how can this year 2038 problem<br>
> be addressed?<br>
> <br>
> I am pretty sure a ticket is needed but I wanted to discuss this and understand<br>
> the scope.<br>
> <br>
> We may also have similar issues in other file systems that we didn't spot.<br>
<br>
Did this get resolved?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">I've been letting the RSB patch be committed a bit before pushing the others since it is a break.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Chris<br>
  (still under his rock)<br>
</blockquote></div></div></div>