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
WARNING: multiple messages have this Message-ID (diff)
From: Takashi Iwai <tiwai@suse.de>
To: Baolin Wang <baolin.wang@linaro.org>
Cc: fabf@skynet.be, alsa-devel@alsa-project.org,
dharageswari.r@intel.com, linux-kernel@vger.kernel.org,
arnd@arndb.de, vinod.koul@intel.com, hardik.t.shah@intel.com,
guneshwor.o.singh@intel.com, lgirdwood@gmail.com,
gudishax.kranthikumar@intel.com, broonie@kernel.org,
deepa.kernel@gmail.com, jeeja.kp@intel.com,
elfring@users.sourceforge.net, arvind.yadav.cs@gmail.com,
naveen.m@intel.com, dan.carpenter@oracle.com, mingo@kernel.org,
bhumirks@gmail.com, o-takashi@sakamocchi.jp
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: 41+ 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 9:31 ` Takashi Iwai
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-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-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-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-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 7:57 ` Arnd Bergmann
2017-09-22 8:38 ` Baolin Wang
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:15 ` Mark Brown
2017-09-22 9:17 ` Takashi Iwai
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.