On Wed, Jan 15, 2020 at 5:32 PM Laurent Vivier <laur...@vivier.eu> wrote:
>
> Le 15/01/2020 à 17:18, Arnd Bergmann a écrit :
> > On Wed, Jan 15, 2020 at 4:53 PM Filip Bozuta <filip.boz...@rt-rk.com> wrote:
> >>
> >> This patch implements functionality of following ioctl:
> >>
> >> SNDRV_TIMER_IOCTL_TREAD - Setting enhanced time read
> >>
> >> Sets enhanced time read which is used for reading time with timestamps
> >> and events. The third ioctl's argument is a pointer to an 'int'.
> >> Enhanced
> >> reading is set if the third argument is different than 0, otherwise
> >> normal
> >> time reading is set.
> >>
> >> Implementation notes:
> >>
> >> Because the implemented ioctl has 'int' as its third argument, the
> >> implementation was straightforward.
> >>
> >> Signed-off-by: Filip Bozuta <filip.boz...@rt-rk.com>
> >
> > I think this one is wrong when you go between 32-bit and 64-bit
>
> kernel uses an "int" and "int" is always 32bit.
> The problem is most likely with timespec I think.
>
> > targets, and it gets worse with the kernel patches that just got
> > merged for linux-5.5, which extends the behavior to deal with
> > 64-bit time_t on 32-bit architectures.
> >
> > Please have a look at
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?h=80fe7430c70859
>
> Yes, we already had the same kind of problem with SIOCGSTAMP and
> SIOCGSTAMPNS.
>
> Do the kernel patches add new ioctl numbers to differentiate 32bit and
> 64bit time_t?
Yes, though SNDRV_TIMER_IOCTL_TREAD is worse: the ioctl argument
is a pure 'int' that decides what format you get when you 'read' from the
same file descriptor.
For emulating 64-bit on 32-bit kernels, you have to use the new
SNDRV_TIMER_IOCTL_TREAD64, and for emulating 32-bit on
64-bit kernels, you probably have to return -ENOTTY to
SNDRV_TIMER_IOCTL_TREAD_OLD unless you also want to
emulate the read() behavior.
When a 32-bit process calls SNDRV_TIMER_IOCTL_TREAD64,
you can translate that into the 64-bit
SNDRV_TIMER_IOCTL_TREAD_OLD.
Arnd
