From: Takashi Iwai <tiwai@suse.de>
To: "Baolin Wang" <baolin.wang@linaro.org>
Cc: <perex@perex.cz>, <alsa-devel@alsa-project.org>, <arnd@arndb.de>,
<arvind.yadav.cs@gmail.com>, <bhumirks@gmail.com>,
<deepa.kernel@gmail.com>, <lgirdwood@gmail.com>,
<dharageswari.r@intel.com>, <gudishax.kranthikumar@intel.com>,
<guneshwor.o.singh@intel.com>, <hardik.t.shah@intel.com>,
<jeeja.kp@intel.com>, <naveen.m@intel.com>,
<vinod.koul@intel.com>, <broonie@kernel.org>, <mingo@kernel.org>,
<dan.carpenter@oracle.com>, <o-takashi@sakamocchi.jp>,
<fabf@skynet.be>, <elfring@users.sourceforge.net>,
<linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 2/7] sound: core: Avoid using timespec for struct snd_pcm_status
Date: Fri, 22 Sep 2017 11:31:25 +0200 [thread overview]
Message-ID: <s5hlgl7dqqa.wl-tiwai@suse.de> (raw)
In-Reply-To: <78aa803db47d99c2bee1a4dc8d426621324785b8.1505973912.git.baolin.wang@linaro.org>
On Thu, 21 Sep 2017 08:18:04 +0200,
Baolin Wang wrote:
>
> The struct snd_pcm_status will use 'timespec' type variables to record
> timestamp, which is not year 2038 safe on 32bits system.
>
> Userspace will use SNDRV_PCM_IOCTL_STATUS and SNDRV_PCM_IOCTL_STATUS_EXT
> as commands to issue ioctl() to fill the 'snd_pcm_status' structure in
> userspace. The command number is always defined through _IOR/_IOW/IORW,
> so when userspace changes the definition of 'struct timespec' to use
> 64-bit types, the command number also changes.
>
> Thus in the kernel, we now need to define two versions of each such ioctl
> and corresponding ioctl commands to handle 32bit time_t and 64bit time_t
> in native mode:
> struct snd_pcm_status32 {
> ......
> struct { s32 tv_sec; s32 tv_nsec; } trigger_tstamp;
> struct { s32 tv_sec; s32 tv_nsec; } tstamp;
> ......
> }
>
> struct snd_pcm_status64 {
> ......
> struct { s64 tv_sec; s64 tv_nsec; } trigger_tstamp;
> struct { s64 tv_sec; s64 tv_nsec; } tstamp;
> ......
> }
I'm confused. It's different from timespec64? So 32bit user-space
would need to use a new own-type timespec instead of the standard
timespec that is compliant with y2038?
thanks,
Takashi
next prev parent reply other threads:[~2017-09-22 9:31 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-21 6:18 [RFC PATCH 0/7] Fix year 2038 issue for sound subsystem Baolin Wang
2017-09-21 6:18 ` [RFC PATCH 1/7] sound: Replace timespec with timespec64 Baolin Wang
2017-09-21 10:02 ` Arnd Bergmann
2017-09-21 6:18 ` [RFC PATCH 2/7] sound: core: Avoid using timespec for struct snd_pcm_status Baolin Wang
2017-09-22 9:31 ` Takashi Iwai [this message]
2017-09-22 10:14 ` Arnd Bergmann
2017-09-22 10:49 ` Takashi Iwai
2017-09-22 11:43 ` Arnd Bergmann
2017-09-22 12:19 ` Takashi Iwai
2017-09-21 6:18 ` [RFC PATCH 3/7] sound: core: Avoid using timespec for struct snd_pcm_sync_ptr Baolin Wang
2017-09-21 12:50 ` Arnd Bergmann
2017-09-22 6:47 ` Baolin Wang
2017-09-22 8:48 ` Arnd Bergmann
2017-09-26 22:24 ` Baolin Wang
2017-09-21 6:18 ` [RFC PATCH 4/7] sound: core: Avoid using timespec for struct snd_rawmidi_status Baolin Wang
2017-09-21 12:56 ` Arnd Bergmann
2017-09-22 1:54 ` Baolin Wang
2017-09-21 6:18 ` [RFC PATCH 5/7] sound: core: Avoid using timespec for struct snd_timer_status Baolin Wang
2017-09-21 13:14 ` Arnd Bergmann
2017-09-22 2:03 ` Baolin Wang
2017-09-21 6:18 ` [RFC PATCH 6/7] uapi: sound: Avoid using timespec for struct snd_ctl_elem_value Baolin Wang
2017-09-21 12:58 ` Arnd Bergmann
2017-09-26 21:54 ` Baolin Wang
2017-09-21 6:18 ` [RFC PATCH 7/7] sound: core: Avoid using timespec for struct snd_timer_tread Baolin Wang
2017-09-21 13:09 ` Arnd Bergmann
2017-09-22 3:00 ` Baolin Wang
2017-09-22 7:57 ` Arnd Bergmann
2017-09-22 8:38 ` Baolin Wang
2017-09-22 4:07 ` [RFC PATCH 0/7] Fix year 2038 issue for sound subsystem Takashi Sakamoto
2017-09-22 5:30 ` Baolin Wang
2017-09-22 9:15 ` Mark Brown
2017-09-22 9:17 ` Takashi Iwai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=s5hlgl7dqqa.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=arnd@arndb.de \
--cc=arvind.yadav.cs@gmail.com \
--cc=baolin.wang@linaro.org \
--cc=bhumirks@gmail.com \
--cc=broonie@kernel.org \
--cc=dan.carpenter@oracle.com \
--cc=deepa.kernel@gmail.com \
--cc=dharageswari.r@intel.com \
--cc=elfring@users.sourceforge.net \
--cc=fabf@skynet.be \
--cc=gudishax.kranthikumar@intel.com \
--cc=guneshwor.o.singh@intel.com \
--cc=hardik.t.shah@intel.com \
--cc=jeeja.kp@intel.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=naveen.m@intel.com \
--cc=o-takashi@sakamocchi.jp \
--cc=perex@perex.cz \
--cc=vinod.koul@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox