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?
-
