[PATCH v2] legacy nfs.c: Change filesystem utime_h handler to utimens_h
Ryan Long
ryan.long at oarcorp.com
Fri May 28 14:14:18 UTC 2021
Reply is below.
From: Joel Sherrill <joel at rtems.org>
Sent: Friday, May 21, 2021 9:44 AM
To: Gedare Bloom <gedare at rtems.org>
Cc: Ryan Long <ryan.long at oarcorp.com>; vijay at rtems.rog; rtems-devel at rtems.org <devel at rtems.org>
Subject: Re: [PATCH v2] legacy nfs.c: Change filesystem utime_h handler to utimens_h
As a warning, this and the corresponding libbsd patch are queued
behind an RSB patch to get UTIME_NOW and UTIME_OMIT in
newlib. That patch was merged into newlib. Then the RTEMS
*utime* patch set and these two will go in at the same time. Otherwise,
there will be breakage.
On Fri, May 21, 2021 at 9:26 AM Gedare Bloom <gedare at rtems.org<mailto:gedare at rtems.org>> wrote:
On Mon, May 3, 2021 at 12:41 PM Ryan Long <ryan.long at oarcorp.com<mailto:ryan.long at oarcorp.com>> wrote:
>
> Changed nfs_utime() to nfs_utimens(), changed the arguments to use
> a timespec array instead of individual variables for access and
> modified time.
>
> Updates #4400
> ---
> nfsclient/src/nfs.c | 50 +++++++++++++++++++++++++-------------------------
> 1 file changed, 25 insertions(+), 25 deletions(-)
>
> diff --git a/nfsclient/src/nfs.c b/nfsclient/src/nfs.c
> index bc9a2c6..72fefb9 100644
> --- a/nfsclient/src/nfs.c
> +++ b/nfsclient/src/nfs.c
> @@ -2050,19 +2050,19 @@ static int nfs_rmnod(
> return rv;
> }
>
> -static int nfs_utime(
> +static int nfs_utimens(
> const rtems_filesystem_location_info_t *pathloc, /* IN */
> - time_t actime, /* IN */
> - time_t modtime /* IN */
> + struct timespec times[2] /* IN */
> +
> )
> {
> sattr arg;
>
> /* TODO: add rtems EPOCH - UNIX EPOCH seconds */
> - arg.atime.seconds = actime;
> - arg.atime.useconds = 0;
> - arg.mtime.seconds = modtime;
> - arg.mtime.useconds = 0;
> + arg.atime.seconds = times[0].tv_sec;
> + arg.atime.useconds = times[0].tv_nsec / 1000;
Do we have a macro exposed for this, like in
TOD_NANOSECONDS_PER_MICROSECOND? If not, this is fine I suppose.
This wouldn't be public since it doesn't start with RTEMS_ and I don't
see any of the TOD_ constants redefined in the RTEMS namespace.
> + arg.mtime.seconds = times[1].tv_sec;
> + arg.mtime.useconds = times[1].tv_nsec / 1000;
>
> return nfs_sattr(pathloc->node_access, &arg, SATTR_ATIME | SATTR_MTIME);
> }
> @@ -2254,25 +2254,25 @@ sattr arg;
> }
>
> const struct _rtems_filesystem_operations_table nfs_fs_ops = {
> - .lock_h = nfs_lock,
> - .unlock_h = nfs_unlock,
> - .eval_path_h = nfs_eval_path,
> - .link_h = nfs_link,
> + .lock_h = nfs_lock,
> + .unlock_h = nfs_unlock,
> + .eval_path_h = nfs_eval_path,
> + .link_h = nfs_link,
> .are_nodes_equal_h = nfs_are_nodes_equal,
> - .mknod_h = nfs_mknod,
> - .rmnod_h = nfs_rmnod,
> - .fchmod_h = nfs_fchmod,
> - .chown_h = nfs_chown,
> - .clonenod_h = nfs_clonenode,
> - .freenod_h = nfs_freenode,
> - .mount_h = rtems_filesystem_default_mount,
> - .unmount_h = rtems_filesystem_default_unmount,
> - .fsunmount_me_h = nfs_fsunmount_me,
> - .utime_h = nfs_utime,
> - .symlink_h = nfs_symlink,
> - .readlink_h = nfs_readlink,
> - .rename_h = nfs_rename,
> - .statvfs_h = rtems_filesystem_default_statvfs
> + .mknod_h = nfs_mknod,
> + .rmnod_h = nfs_rmnod,
> + .fchmod_h = nfs_fchmod,
> + .chown_h = nfs_chown,
> + .clonenod_h = nfs_clonenode,
> + .freenod_h = nfs_freenode,
> + .mount_h = rtems_filesystem_default_mount,
> + .unmount_h = rtems_filesystem_default_unmount,
> + .fsunmount_me_h = nfs_fsunmount_me,
> + .utimens_h = nfs_utimens,
> + .symlink_h = nfs_symlink,
> + .readlink_h = nfs_readlink,
> + .rename_h = nfs_rename,
> + .statvfs_h = rtems_filesystem_default_statvfs
Why so many additional whitespace changes?
[Ryan Long] When I changed utime_h to utimens_h, it got everything out of alignment, so I moved everything over.
> };
>
> /*****************************************
> --
> 1.8.3.1
>
> _______________________________________________
> devel mailing list
> devel at rtems.org<mailto:devel at rtems.org>
> http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel at rtems.org<mailto:devel at rtems.org>
http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210528/3b7583d6/attachment-0001.html>
More information about the devel
mailing list