On Wed, Jan 15, 2020 at 8:17 PM Filip Bozuta <filip.boz...@rt-rk.com> wrote:
> On 15.1.20. 17:37, Arnd Bergmann wrote:
> > 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:
> >> 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.
>
> Thank you for bringing this up to my attention. Unfortunately i have
> some duties of academic nature in next month so i won't have much time
> fix this bug. I will try to fix this as soon as possible.
One more thing: I just realized it gets worse when emulating cross-endian,
as then even without calling SNDRV_TIMER_IOCTL_TREAD, reading
data from /dev/snd/timer requires byteswapping the two words.
Arnd
