On Tue, Nov 12, 2019 at 9:37 PM Takashi Iwai tiwai@suse.de wrote:
On Tue, 12 Nov 2019 16:16:34 +0100, Arnd Bergmann wrote:
I would like to propose merging this into the alsa tree after the v5.5 merge window for inclusion into v5.6, to allow a good amount of testing, in particular for the header changes that may cause problems for user space applications.
Agreed, it's still no urgent problem.
I actually do think it's getting urgent, anything that touches the ABI must be done carefully and not rushed.
The urgency at the moment is that developers are starting to deploy systems with 64-bit time_t with musl-libc making this the default now, and 32-bit risc-v not offering 32-bit time_t at all.
At the moment, this means that audio support is broken for them, and that needs to be fixed.
The other reason why lots of people care about moving all user space to 64-bit time_t is that 32-bit hardware is slowly starting to become less common. We know there will still be many 32-bit ARM systems operational in 2038, but most of them will be on (then) 10+ year old hardware, running even older software that already being worked on today. The longer it takes us to stop using 32-bit time_t in user space, the more systems will end up having to be thrown away rather than fixed.
So now taking a quick look through the series, I find this approach is the way to go. Although one might get a bit more optimization after squeeze, it's already a good compromise between the readability and the efficiency.
Thanks!
A slight uncertain implementation is the timer tread stuff, especially the conditional definition of SNDRV_TIMER_IOCTL_TREAD (IIRC, I already complained it in the past, too). But I have no other idea as well, so unless someone else gives a better option, we can live with that.
We had discussed alternatives for this one last time, and decided to go with the solution I posted here. The main alternative would be to change the 'timespec' in snd_timer_tread to a fixed-length structure based on two 'long' members. This would avoid the need to match the command with the time_t type, but the cost would be requiring CLOCK_MONOTONIC timestamps to avoid the overflow, and changing all application source code that requires the type to be compatible with 'timespec'.
Arnd