Received: by 10.192.165.148 with SMTP id m20csp2212521imm; Thu, 26 Apr 2018 07:33:52 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqAZi8bc1pH7Nih6nM2oXHOnTxXrKsrCEQOudimrJZ5lrmkK2ms3yt4ubL3vvmAiD395+Si X-Received: by 2002:a17:902:5902:: with SMTP id o2-v6mr11958509pli.79.1524753232603; Thu, 26 Apr 2018 07:33:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524753232; cv=none; d=google.com; s=arc-20160816; b=a3nycN/1oZfDafhrHCgQ3OaFkOH0D7NNMSuRmlDalPwxIXal4vcFbUxu22xqJqn+CO JQxXO4kLlyQScMw2cmp8iUmADSisKdzAckfPJojJtODvgVWa0W8j+GZSDHwMnpJUUJlG ABhWCaQPhdc/f4xVjFW+5YUq5Sm8GDaN3S0qve4BZN1hwhhAGJvm1vL2sRVNEBW71YXw qHEDH4HP4L/DMywBAqGXNJhxnvA++SysRa2QHdHWZatW3RW9ria1Ik56IwQtcjIiZ9sv RXfeD4B9R7lXEVZug0Qj/Ktdl9u9f6Ajgfl4CADrjCLo8rw1sEYKMwwHWpe5r37MfRbT z4HQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=mLQocTVe7pCNAtW1qvojX4SAyE8lJ7F7tQb5At2HwDs=; b=QpcKPBdMwn/qBw0Ts8jK0r91tpvZjkbQVDf4LmIhHHdM3HdSsHb9yka8BAJeMyQwgh mPfZejUs2CekR3YWxtnkSezSFxT+QlR6DM/dqKpmE1CO9nV/aHCPO1o2CjBb44LKpOOq AVDq18xDPV3fSyRtSFbyze87vDF/AFzi8Ye/6xJCU9HWiDKx6omIcjGf3zseZUro8UvQ 0YWrtvu0t8HG/v9eoEULWTOYwwtxUXbhmcB705uP/kSyLA1pFd2Ua2HE5i4m8NKckK4g hLL9pP62obMAX5fc3e7qHvVXtLwxZwRLqlVaTmy5ykkk6W3Bps1GoHLBaw1aZBbD35xW mwzQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=uWeuYhnv; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a33-v6si15737378pli.275.2018.04.26.07.33.38; Thu, 26 Apr 2018 07:33:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=uWeuYhnv; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756559AbeDZOcE (ORCPT + 99 others); Thu, 26 Apr 2018 10:32:04 -0400 Received: from mail-qt0-f194.google.com ([209.85.216.194]:46793 "EHLO mail-qt0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756262AbeDZOcC (ORCPT ); Thu, 26 Apr 2018 10:32:02 -0400 Received: by mail-qt0-f194.google.com with SMTP id m16-v6so8304369qtg.13 for ; Thu, 26 Apr 2018 07:32:02 -0700 (PDT) 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; bh=mLQocTVe7pCNAtW1qvojX4SAyE8lJ7F7tQb5At2HwDs=; b=uWeuYhnvUvJ7kxUA716cgTUW2KTdhGxVZUqrJxmdBucjXDIGN306mtnQisGex+SAmU b/xtnLfV8EAEZWTLVxi51pQXevyldZeZ02IR/OMWs4td8aRlWHApuCbtRkRu4Qmet3WZ RBZ13UwuA4oSJSm43cLFJa8aN77sH4A3BwJknP3gTQ9FFcAb5qtYaNpy3VgJ49d+6hJh gGcWtAw/sHuHUC3wfeM9vrepsqgR1aNx/4W9vHLnqZWly5A2N1YI1gvs25n1PlfyP3jC lTN04XiLMj1jxPvy+5lhLd0v4dojhhuwnv7xGOtFMmQwRNbAAZvSZWKunkdi3P3v7Q3l Le+Q== 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; bh=mLQocTVe7pCNAtW1qvojX4SAyE8lJ7F7tQb5At2HwDs=; b=DqbC6yrUOK5/3zF5Ntof+FX57KxELnhMAv7NvmueVl0OsWTpFnVwm/gKQgYEsQ/deX mHRI13foA/wxkpMOtlhp9dulAWStOPS1MWEtzftw6GJ6jylFXUBTHZ5cXsCnoxBbjc+f UwpZ9bbI1zckJK3MCuLjkRpbzt96oTDhzQP2ILH3qjsTIv7FrLFPJzEIHmgOHCE69FyE TyugB9ReP6etGuqasOHZ7CA3WhSrgu3DrDbg/myD+F7ptn8biVhzbcix4KctzEGr3Drk 03cFFHL4kZvcY/FtYSRj4rzGJCj3RY2eI78RmWEvf0rj7oDxZiKbKaFqmsG1EpssMwS2 TY3g== X-Gm-Message-State: ALQs6tB80bldT8iOOoe7vGOAslm0QpzSg5XdbwWTF67l1qiFht0VwTKZ XTEtxasBR3Y5BUXxp5VPJOSb/5l+YsQCv3CokZE= X-Received: by 10.12.189.164 with SMTP id n36mr12834454qvg.151.1524753121803; Thu, 26 Apr 2018 07:32:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.185.3 with HTTP; Thu, 26 Apr 2018 07:32:01 -0700 (PDT) In-Reply-To: <6aa760e5-390a-b7ba-62f1-dc01308031fa@perex.cz> References: <20180426124422.2921744-1-arnd@arndb.de> <6aa760e5-390a-b7ba-62f1-dc01308031fa@perex.cz> From: Arnd Bergmann Date: Thu, 26 Apr 2018 16:32:01 +0200 X-Google-Sender-Auth: hXjvxt_oZfJtvTpGkoRxvURoclo Message-ID: Subject: Re: [PATCH 0/4] ALSA: Fix year 2038 issue for sound subsystem, alternative To: Jaroslav Kysela Cc: y2038 Mailman List , Linux Kernel Mailing List , Takashi Iwai , Liam Girdwood , Mark Brown , Takashi Sakamoto , alsa-devel@alsa-project.org, Baolin Wang Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 26, 2018 at 3:30 PM, Jaroslav Kysela wrote: > Dne 26.4.2018 v 14:44 Arnd Bergmann napsal(a): >> I've tried the suggestion from Jaroslaw, doing a minimal change to the >> UAPI headers to keep the existing binary interface. As he predicted, >> this is a much simpler set of kernel changes, but we will pay for that >> with added complexity in alsa-lib. >> >> The first two patches in this series are taken from Baolin's patch >> set, with a small bugfix folded in to avoid a compile-time regression. >> >> The other two patches are to redefine the UAPI and to deprecate >> the support for CLOCK_REALTIME time stamps, which we can no longer >> allow with user space that we expect to survive beyond 2038. >> >> Overall, I'd still be happier with Baolin's approach since it allows >> us to keep compatiblity with CLOCK_REALTIME users and requires >> fewer changes in user space, but this would work as well. > > Hi Arnd, > > Thanks for your work. I proposed a bit different implementation. Example: > > struct snd_example { > struct snd_native_timespec tstamp; > .... > u64 tstamp_sec64; /* use the reserved[] array for this */ > }; > > So tstamp contains the current 32-bit tv_sec/tv_nsec and the full > 64-bit value is in tstamp_sec64. In this way, we can transfer any type > of the timespec64 values and it's backward compatible to retain the > binary compatibility. The protocol versions should be increased to let > the userspace know about the new 64-bit fields. Right, I went in a slightly different way since the intention was to keep the interface simple. I think we can either force the use of monotonic times or extend it to 64-bit CLOCK_REALTIME stamps, but the monotonic stamps seem much better for multiple reasons (i.e. skipping) if you want to avoid introducing new ioctls. The added complexity of having two timestamps in a single structure means we don't end up with much simpler code that what Baolin proposed, which mostly just moves the existing compat_ioctl() to the native 32-bit handler but not add anything new that requires library changes. His tread patch and my mmap patch both do add some complexity but then we also need some of that with your suggestions for tread. > The timer read protocol must be updated, because the stream will > change, so I am fine to add new ioctl (like originally proposed). With forced monotonic times, we can skip that update and keep using the existing stream format. > The alsa-lib defines timespec only if posix defines are not set so > glibc's time.h does not define the timespec structure - it may be improved. Yes, we definitely need to improve that, since any application that relies on the timespec definition to come from alsa would otherwise get a structure with a 64-bit tv_sec but incorrect padding on tv_nsec (no padding on i386, padding on the wrong side for big-endian architectures). One way out would be to define snd_timestamp_t and snd_htimestamp_t in terms of snd_monotonic_timestamp from the kernel header and let it still have the traditional layout even for applications built with 64-bit time_t. The downside is again that applications may break when they cast between snd_htimestamp_t and timespec pointers. Arnd