Re: [PATCH v6 0/8] Fix year 2038 issue for sound subsystem

From: Takashi Iwai <tiwai@suse.de>
To: Arnd Bergmann <arnd@arndb.de>
Cc: ALSA Development Mailing List <alsa-devel@alsa-project.org>,
	Takashi Iwai <tiwai@suse.com>,
	Baolin Wang <baolin.wang7@gmail.com>,
	y2038 Mailman List <y2038@lists.linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jaroslav Kysela <perex@perex.cz>, Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH v6 0/8] Fix year 2038 issue for sound subsystem
Date: Wed, 13 Nov 2019 17:40:43 +0100	[thread overview]
Message-ID: <s5hzhgzn304.wl-tiwai@suse.de> (raw)
In-Reply-To: <CAK8P3a2TMEUhzxH7RKvAW9STk33KrbCriUaQawOMffoFC6UTQw@mail.gmail.com>

On Wed, 13 Nov 2019 15:32:44 +0100,
Arnd Bergmann wrote:
> 
> 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.

Don't worry, I planned merging the whole changes for 5.6.

> > 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'.

Fair enough.

One thing I forgot to mention: when we add/modify the ioctl or ABI, we
need to increment the protocol version, e.g. SNDRV_PCM_VERSION to
indicate user-space the supported ABI.  Please change these in your
next patches, too.

thanks,

Takashi