On 2021年03月10日 15:51, florian.bezdeka--- via Xenomai wrote:
On Tue, 2021-03-09 at 07:53 +0000, florian.bezdeka--- via Xenomai
wrote:
On Mon, 2021-03-08 at 19:28 +0100, Jan Kiszka wrote:
On 08.03.21 18:02, Florian Bezdeka wrote:
Implementation is heavily inspired by the sem_timedwait syscall,
but expecting time64 based timespec / timeout.
[snip]
@@ -82,6 +83,28 @@ static inline int cobalt_strncpy_from_user(char *dst, const
char __user *src,
return __xn_strncpy_from_user(dst, src, count);
}
+static inline int cobalt_get_timespec64(struct timespec64 *ts,
+ const struct __kernel_timespec __user *uts)
+{
+ struct __kernel_timespec kts;
+ int ret;
+
+ ret = cobalt_copy_from_user(&kts, uts, sizeof(kts));
+ if (ret)
+ return -EFAULT;
+
+ ts->tv_sec = kts.tv_sec;
+
+ /* Zero out the padding in compat mode */
+ if (in_compat_syscall())
+ kts.tv_nsec &= 0xFFFFFFFFUL;
+
+ /* In 32-bit mode, this drops the padding */
+ ts->tv_nsec = kts.tv_nsec;
+
+ return 0;
+}
+
Why inline? But that question is likely obsolete when we can avoid the
code duplication below.
Inline can be removed. Something for v3. There will follow more calls
to that helper. All syscalls reading a struct timespec from userspace
will have to use it.
I was following the pattern of all the other struct timespec64 heplers
introduced by Philippe here. So "static inline". Removing "inline" now
throws some warnings (at least on gcc 10), because the function is
unused in this file.
So my question is now: Where should this function reside?
Linux pattern: kernel/time/time.c (where get_timespec64 resides)
Xenomai path would be kernel/cobalt/time.c
This is the last thing I have to address. A non RFC series will follow
afterwards, based on Philippe's tree.
@Song: My hope was this series can be used as pattern, to start
integration of all the other remaining parts. What do you think? Is
that sufficient?
This series look good to me and i'm following it to work on my patches.
Song
-
