Le 15/01/2020 à 20:51, Arnd Bergmann a écrit : > 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.
We already have this case with netlink and we are able to translate data on the fly. Thanks, Laurent
