Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1737282

Re: [RFC PATCH 3/7] sound: core: Avoid using timespec for struct snd_pcm_sync_ptr

Path csiph.com!news.redatomik.org!weretis.net!feeder4.news.weretis.net!news.unit0.net!news.panservice.it!bofh.it!news.nic.it!robomod
From Arnd Bergmann <arnd@arndb.de>
Newsgroups linux.kernel
Subject Re: [RFC PATCH 3/7] sound: core: Avoid using timespec for struct snd_pcm_sync_ptr
Date Fri, 22 Sep 2017 10:50:01 +0200
Message-ID <usrON-3W2-9@gated-at.bofh.it> (permalink)
References <us305-5ww-3@gated-at.bofh.it> <us305-5ww-13@gated-at.bofh.it> <us9fc-16W-11@gated-at.bofh.it> <uspWF-2Qj-15@gated-at.bofh.it>
Dkim-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=447RiTpNndTf/c+j59W1cMXaOBSMghYPUtBv5ueMBh4=; b=Qu5t8umSoe1yslVCRfZ+WZKqB098x0w7p0ILiYN740paknG3hpaviQ12yvT3jzv+0E ZL0GkBLLDCRZjy7p4Omj3zSVugNhcGYO9P3Zs+/fm9xy64JGxHBrHt3hE+MUVcMCJgSt Z/tNTnkX4PtRnCSnQOW3+kPfx9/t/WVeiWpTD9q57tn2NrlYlPXyDM6pMiGKJvYdmpKg Xn/F0mTon1OdGZgp1mqT2bDClyC2scolNF1XOifaPU+uvOIwbEKrL1FQwR2A6LsFXtuo d6UM+N5lzMwz1NUiKQqb+bqKR9O/v1EzGxNw4N5kpPmvK68bIXPN+B9pi8l9Yv825MOt re+g==
X-Google-Dkim-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=447RiTpNndTf/c+j59W1cMXaOBSMghYPUtBv5ueMBh4=; b=JuqFw2o1reijFCiFJilXW8dZ729/2yMLwwknVJWAo9jZpVlVmTMlQdlgwXY4FcYdfw +4Aqf6b5fGTZ7ox9l5XTGhMFuykhA0jaEirM8g3rdPyT/KOj9ZPrk8OHPLEe+2l9BKUT dxMy/l6eZe8VllSvY4P4ShppqP4eSzuKy/qOqR6drKUPs5hSQmSkadURgyanx73j4adl eGBwUlFwAdKVnjXujId+AvX6MUNtnrBnfZ4p3x2KlEt5WXpgzKdL7F279ivPrHn7Yj3K krj89moBf7HKHwrPTVw23HfxTsgqgGTAqhgjnhqYi4zFY0OMqNS+UooprFePwif1Luz8 0F0Q==
X-Gm-Message-State AHPjjUgAQiIIgEP2VYX//vb+L6xAaXhsBpL5pw5Ol5/zlrRUzYyMHM/S kiMplf124EkLEAyou86TJPG+Ni4l+tDe3yYzkkE=
X-Google-SMTP-Source AOwi7QBaOL2aUOev4hrHhld8HqjHQtM7ePlSfpnNGRRAjIftbGa2gqD5IQrxWfDtiTLOv/aJlj4ZAXHEmrTBekLnyRQ=
X-Received by 10.202.236.131 with SMTP id k125mr5367082oih.313.1506070130668; Fri, 22 Sep 2017 01:48:50 -0700 (PDT)
MIME-Version 1.0
X-Google-Sender-Auth OH_D4ds2hf02X0X3tAPSQ4BH8Ko
Content-Type text/plain; charset="UTF-8"
Content-Transfer-Encoding quoted-printable
Sender robomod@news.nic.it
List-ID <linux-kernel.vger.kernel.org>
X-Mailing-List linux-kernel@vger.kernel.org
Approved robomod@news.nic.it
Lines 63
Organization linux.* mail to news gateway
X-Original-Cc Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>, Liam Girdwood <lgirdwood@gmail.com>, Ingo Molnar <mingo@kernel.org>, Takashi Sakamoto <o-takashi@sakamocchi.jp>, SF Markus Elfring <elfring@users.sourceforge.net>, Dan Carpenter <dan.carpenter@oracle.com>, jeeja.kp@intel.com, Vinod Koul <vinod.koul@intel.com>, dharageswari.r@intel.com, guneshwor.o.singh@intel.com, Bhumika Goyal <bhumirks@gmail.com>, gudishax.kranthikumar@intel.com, Naveen M <naveen.m@intel.com>, hardik.t.shah@intel.com, Arvind Yadav <arvind.yadav.cs@gmail.com>, Fabian Frederick <fabf@skynet.be>, Mark Brown <broonie@kernel.org>, Deepa Dinamani <deepa.kernel@gmail.com>, alsa-devel@alsa-project.org, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
X-Original-Date Fri, 22 Sep 2017 10:48:50 +0200
X-Original-Message-ID <CAK8P3a1Rw3H5TA6VDB0_vH+vVk57bCGemT1Xw=z03Tbv4Hfm6Q@mail.gmail.com>
X-Original-References <cover.1505973912.git.baolin.wang@linaro.org> <6781c7b4e5934ad65e3c5b401c0a1bbd7cb44db6.1505973912.git.baolin.wang@linaro.org> <CAK8P3a2+A4d7P27v7hn7777zyH1m65_1+DYNA4mUfqTxct9R_A@mail.gmail.com> <CAMz4kuK7=+fx+8qJKVxCDOL01UmZeoP8R7iRJg04B0zVmdXp0g@mail.gmail.com>
X-Original-Sender linux-kernel-owner@vger.kernel.org
Xref csiph.com linux.kernel:1737282

Show key headers only | View raw


On Fri, Sep 22, 2017 at 8:47 AM, Baolin Wang <baolin.wang@linaro.org> wrote:
> On 21 September 2017 at 20:50, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Thu, Sep 21, 2017 at 8:18 AM, Baolin Wang <baolin.wang@linaro.org> wrote:
>>> The struct snd_pcm_sync_ptr will use 'timespec' type variables to record
>>
>> This looks correct, but there is a subtlety here to note about x86-32
>> that we discussed in a previous (private) review. To recall my earlier
>> thoughts:
>>
>> Normal architectures insert 32 bit padding after 'suspended_state',
>> and 32-bit architectures (including x32) also after hw_ptr,
>> but x86-32 does not. You make that explicit in the compat code,
>> this version just relies on the compiler using identical padding
>> in user and kernel space. We could make that explicit using
>>
>> struct snd_pcm_mmap_status64 {
>>        snd_pcm_state_t state;          /* RO: state - SNDRV_PCM_STATE_XXXX */
>>        int pad1;                       /* Needed for 64 bit alignment */
>>        snd_pcm_uframes_t hw_ptr;       /* RO: hw ptr (0...boundary-1) */
>> #if !defined(CONFIG_64BIT) && !defined(CONFIG_X86_32)
>>        int pad2;
>> #endif
>>       struct { s64 tv_sec; s64 tv_nsec; } tstamp;             /* Timestamp */
>>        snd_pcm_state_t suspended_state; /* RO: suspended stream state */
>> #if !defined(CONFIG_X86_32)
>>        int pad3;
>> #endif
>>       struct { s64 tv_sec; s64 tv_nsec; } audio_tstamp;       /* from
>> sample counter or wall clock */
>> };
>
> I am sorry I did not get you here, why we do not need pad2 and pad3
> for x86_32?

This is again the x86-32 alignment quirk: the structure as defined
in the uapi header does not have padding, and the new s64 fields
have 32-bit alignment on x86, so the compiler does not add implicit
padding in user space.

On all other architectures, the fields do get padded implicitly
in user space, I'm just listing the padding explicitly.

> You missed ‘#if !defined(CONFIG_64BIT)“ at the second #if
> condition?

No, that was intentional:

snd_pcm_uframes_t is 'unsigned long', so on 64-bit architectures
we have no padding between two 64-bit values (hw_ptr and tstamp),
and on x86-32 we have no padding because both have 32-bit
alignment.

However, snd_pcm_state_t is 'int', which is always 32-bit wide,
so we do have padding on both 32-bit and 64-bit architectures
between syspended_state and audio_tstamp, with the exception
of x86-32.

      Arnd

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

[RFC PATCH 3/7] sound: core: Avoid using timespec for struct snd_pcm_sync_ptr Baolin Wang <baolin.wang@linaro.org> - 2017-09-21 08:20 +0200
  Re: [RFC PATCH 3/7] sound: core: Avoid using timespec for struct snd_pcm_sync_ptr Arnd Bergmann <arnd@arndb.de> - 2017-09-21 15:00 +0200
    Re: [RFC PATCH 3/7] sound: core: Avoid using timespec for struct snd_pcm_sync_ptr Baolin Wang <baolin.wang@linaro.org> - 2017-09-22 08:50 +0200
      Re: [RFC PATCH 3/7] sound: core: Avoid using timespec for struct snd_pcm_sync_ptr Arnd Bergmann <arnd@arndb.de> - 2017-09-22 10:50 +0200

csiph-web