On Wed, Jan 15, 2020 at 5:32 PM Laurent Vivier <address@hidden> wrote:
Le 15/01/2020 à 17:18, Arnd Bergmann a écrit :
On Wed, Jan 15, 2020 at 4:53 PM Filip Bozuta <address@hidden> 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 <address@hidden>
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