From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DFE83C33CB1 for ; Thu, 16 Jan 2020 11:28:38 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 966EA2073A for ; Thu, 16 Jan 2020 11:28:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="O5tuSPGE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 966EA2073A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:40276 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1is3KH-0002Fn-LL for qemu-devel@archiver.kernel.org; Thu, 16 Jan 2020 06:28:37 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:55268) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1is3Jg-0001q0-6f for qemu-devel@nongnu.org; Thu, 16 Jan 2020 06:28:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1is3Jd-0000P1-G4 for qemu-devel@nongnu.org; Thu, 16 Jan 2020 06:27:59 -0500 Received: from mail-ot1-x344.google.com ([2607:f8b0:4864:20::344]:45179) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1is3Jd-0000NV-7V for qemu-devel@nongnu.org; Thu, 16 Jan 2020 06:27:57 -0500 Received: by mail-ot1-x344.google.com with SMTP id 59so19005250otp.12 for ; Thu, 16 Jan 2020 03:27:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tTI8onj5B4nslbtusEcKMNx9Tnr3ZU5YyH0RvvnCbfU=; b=O5tuSPGEe0i+R+jDUyC6KgygyAq+RlGNuMam8TLogbUwIysUH4Gr/kfQLyTFH1yUxP 4/Lg1fOuy/93ouBiGxLeaCOiijDID9+tiPz5SrjsNwoJUWUpPdo/EJxvhDdjx2C0fM4i XSLu4OziJxAjozUJGTYu/dvj0Ko1fV+3F6VyBL0QB6bBwD10Xp/gYqVhhaMD0AaFpMK5 op9WYAMgeIYJgGd6gBpoXsIVCjU2pSqDNmlPdY49eNNfeVgwh70rGsiZVrsmh36c5KRF tIFuhF5hiur5fYOGEJrvNboxNtJtQe701nCiKUSUtNf3Fjd+CBA5DByjtpvOV3u9GyV0 6YzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tTI8onj5B4nslbtusEcKMNx9Tnr3ZU5YyH0RvvnCbfU=; b=Mooc/XnEmqEr9pD+8cg5oszYjvB+rY0kZ0AO+5XzwI9ltU2jkWLt2stkpSpKuO5Ht6 DfrXPxL+6E2CLI6WpoD0IVCJzWfOWCe/cBIJqQY8Ya4ojWwolo6ez76TpqpbBIukMh/F 41Vi6ONMRjvCJQC1vxjIWLW22L1tEEmLgaLnBgkjolRfDtM5bERkkV6zSm4wVOOTK7HA 5q0LTRIqaj9/4N5+0u071nNxtLJNYuEfVaXeKDd7fIQ1o1owIrYbccIKryVjThqqJrK1 FXhYqxFCKK30K63zAcE/MYIGLLwKeAEtznCPl7C1AdNCnHfOJnJ5nmJ7l46TWZKD1rVb 4PTQ== X-Gm-Message-State: APjAAAX154gMUDaLPQI88ux4pnjE1wmfu1sdQpTBor7/3CGg90wrtXt2 ehHdV3zbmlSEJ+Av7nYJQtmJ+xlh9gmTyaog+6E= X-Google-Smtp-Source: APXvYqytYLTjQPrKILmcvzMhV66Qsapovl311vLqxucK027BmcatCIa6veIZpRoNxP4Lk4oAiF5kEh8QcyoeyzYTay4= X-Received: by 2002:a05:6830:1042:: with SMTP id b2mr1525444otp.306.1579174076076; Thu, 16 Jan 2020 03:27:56 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a9d:d21:0:0:0:0:0 with HTTP; Thu, 16 Jan 2020 03:27:55 -0800 (PST) In-Reply-To: References: <1579103618-20217-1-git-send-email-Filip.Bozuta@rt-rk.com> <1579103618-20217-9-git-send-email-Filip.Bozuta@rt-rk.com> <518d717d-9f1e-e00e-f2a9-df8861241d1c@rt-rk.com> From: Aleksandar Markovic Date: Thu, 16 Jan 2020 12:27:55 +0100 Message-ID: Subject: Re: [PATCH 08/12] linux-user: Add support for setting alsa timer enhanced read using ioctl To: Laurent Vivier Content-Type: multipart/alternative; boundary="000000000000d7d671059c401dc5" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::344 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= , Arnd Bergmann , Richard Henderson , "qemu-devel@nongnu.org" , Filip Bozuta , Max Filippov , "amarkovic@wavecomp.com" , "philmd@redhat.com" Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --000000000000d7d671059c401dc5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thursday, January 16, 2020, Aleksandar Markovic < aleksandar.m.mail@gmail.com> wrote: > > > On Wednesday, January 15, 2020, Laurent Vivier wrote: > >> Le 15/01/2020 =C3=A0 20:17, Filip Bozuta a =C3=A9crit : >> > >> > On 15.1.20. 17:37, Arnd Bergmann wrote: >> >> On Wed, Jan 15, 2020 at 5:32 PM Laurent Vivier >> wrote: >> >>> Le 15/01/2020 =C3=A0 17:18, Arnd Bergmann a =C3=A9crit : >> >>>> On Wed, Jan 15, 2020 at 4:53 PM Filip Bozuta >> >>>> wrote: >> >>>>> This patch implements functionality of following ioctl: >> >>>>> >> >>>>> SNDRV_TIMER_IOCTL_TREAD - Setting enhanced time read >> >>>>> >> >>>>> Sets enhanced time read which is used for reading time with >> >>>>> timestamps >> >>>>> and events. The third ioctl's argument is a pointer to an >> >>>>> 'int'. Enhanced >> >>>>> reading is set if the third argument is different than 0, >> >>>>> otherwise normal >> >>>>> time reading is set. >> >>>>> >> >>>>> Implementation notes: >> >>>>> >> >>>>> Because the implemented ioctl has 'int' as its third argument= , >> >>>>> the >> >>>>> implementation was straightforward. >> >>>>> >> >>>>> Signed-off-by: Filip Bozuta >> >>>> I think this one is wrong when you go between 32-bit and 64-bit >> >>> kernel uses an "int" and "int" is always 32bit. >> >>> The problem is most likely with timespec I think. >> >>> >> >>>> targets, and it gets worse with the kernel patches that just got >> >>>> merged for linux-5.5, which extends the behavior to deal with >> >>>> 64-bit time_t on 32-bit architectures. >> >>>> >> >>>> Please have a look at >> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n >> ext.git/log/?h=3D80fe7430c70859 >> >>>> >> >>> Yes, we already had the same kind of problem with SIOCGSTAMP and >> >>> SIOCGSTAMPNS. >> >>> >> >>> Do the kernel patches add new ioctl numbers to differentiate 32bit a= nd >> >>> 64bit time_t? >> >> Yes, though SNDRV_TIMER_IOCTL_TREAD is worse: the ioctl argument >> >> is a pure 'int' that decides what format you get when you 'read' from >> the >> >> same file descriptor. >> >> >> >> For emulating 64-bit on 32-bit kernels, you have to use the new >> >> SNDRV_TIMER_IOCTL_TREAD64, and for emulating 32-bit on >> >> 64-bit kernels, you probably have to return -ENOTTY to >> >> SNDRV_TIMER_IOCTL_TREAD_OLD unless you also want to >> >> emulate the read() behavior. >> >> When a 32-bit process calls SNDRV_TIMER_IOCTL_TREAD64, >> >> you can translate that into the 64-bit >> >> SNDRV_TIMER_IOCTL_TREAD_OLD. >> >> >> >> Arnd >> > >> > >> > Thank you for bringing this up to my attention. Unfortunately i have >> > some duties of academic nature in next month so i won't have much time >> > fix this bug. I will try to fix this as soon as possible. >> >> Could you at least to try to have a mergeable series before you have to >> stop to work on this? >> >> You can only manage the case before the change reported by Arnd (I will >> manage the new case myself later). >> >> > Hi, all. > > Sorry for interjecting myself into this discussion, but I just want to le= t > you know about some related practicalities. > > Filip is a student that is from time to time (usually between two exam > seasons) an intern in our company, working 4 hours each work day. He spen= t > his internship in different teams in prevous years, and, from around > mid-October 2019, was appointed to QEMU team. After some introductory > tasks, he was assigned his main task: linux-user support for RTCs and ALS= A > timers. This series is the result of his work, and, to my great pleasure, > is virtually entirely his independant work. I am positive he can complete > the series by himself, even in the light of additional complexities > mentioned in this thread. > > However, his exam season just started (Jan. 15th), and lasts till Feb. > 15th. Our policy, in general, is not to burden the students during exam > seasons, and that is why we can't expect prompt updates from him for the > time being. > > In view of this, Laurent, please take Filip's status into consideration. > As far as mergeability is concerned, my impression is that patches 1-6 an= d > 13 are ready for merging, while patches 7-12 would require some additiona= l > (netlink-support-like) work, that would unfortunately be possible only > after Feb. 15th. > > Best wishes, > Aleksandar > > > Laurent, hi again. I am not completely familiar with all details of Filip's work, since, as I said, he had large degree of independance (which was intentional, and is a desired and good thing IMHO), but taking a closer look, a question starting lingering: Do we need special handling od read() even for RTC devices - not only ALSA timer devices? Best regards, Aleksandar > > > Thanks, >> Laurent >> >> >> --000000000000d7d671059c401dc5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thursday, January 16, 2020, Aleksandar Markovic <aleksandar.m.mail@gmail.com> wrot= e:


On Wednesday, January 15, 2020= , Laurent Vivier <laurent@vivier.eu> wrote:
Le 15/0= 1/2020 =C3=A0 20:17, Filip Bozuta a =C3=A9crit=C2=A0:
>
> On 15.1.20. 17:37, Arnd Bergmann wrote:
>> On Wed, Jan 15, 2020 at 5:32 PM Laurent Vivier <laurent@vivier.eu> wrote: >>> Le 15/01/2020 =C3=A0 17:18, Arnd Bergmann a =C3=A9crit :
>>>> On Wed, Jan 15, 2020 at 4:53 PM Filip Bozuta
>>>> <Filip.Bozuta@rt-rk.com> wrote:
>>>>> This patch implements functionality of following ioctl= :
>>>>>
>>>>> SNDRV_TIMER_IOCTL_TREAD - Setting enhanced time read >>>>>
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0 Sets enhanced time read which= is used for reading time with
>>>>> timestamps
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0 and events. The third ioctl&#= 39;s argument is a pointer to an
>>>>> 'int'. Enhanced
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0 reading is set if the third a= rgument is different than 0,
>>>>> otherwise normal
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0 time reading is set.
>>>>>
>>>>> Implementation notes:
>>>>>
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0 Because the implemented ioctl= has 'int' as its third argument,
>>>>> the
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0 implementation was straightfo= rward.
>>>>>
>>>>> Signed-off-by: Filip Bozuta <Filip.Bozuta@rt-rk.com>
>>>> I think this one is wrong when you go between 32-bit and 6= 4-bit
>>> kernel uses an "int" and "int" is always 3= 2bit.
>>> The problem is most likely with timespec I think.
>>>
>>>> targets, and it gets worse with the kernel patches that ju= st got
>>>> merged for linux-5.5, which extends the behavior to deal w= ith
>>>> 64-bit time_t on 32-bit architectures.
>>>>
>>>> Please have a look at
>>>> https://git= .kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?h= =3D80fe7430c70859
>>>>
>>> Yes, we already had the same kind of problem with SIOCGSTAMP a= nd
>>> SIOCGSTAMPNS.
>>>
>>> Do the kernel patches add new ioctl numbers to differentiate 3= 2bit and
>>> 64bit time_t?
>> Yes, though SNDRV_TIMER_IOCTL_TREAD is worse: the ioctl argument >> is a pure 'int' that decides what format you get when you = 'read' from the
>> same file descriptor.
>>
>> For emulating 64-bit on 32-bit kernels, you have to use the new >> SNDRV_TIMER_IOCTL_TREAD64, and for emulating 32-bit on
>> 64-bit kernels, you probably have to return -ENOTTY to
>> SNDRV_TIMER_IOCTL_TREAD_OLD unless you also want to
>> emulate the read() behavior.
>> When a 32-bit process calls SNDRV_TIMER_IOCTL_TREAD64,
>> you can translate that into the 64-bit
>> SNDRV_TIMER_IOCTL_TREAD_OLD.
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Arnd
>
>
> Thank you for bringing this up to my attention. Unfortunately i have > some duties of academic nature in next month so i won't have much = time
> fix this bug. I will try to fix this as soon as possible.

Could you at least to try to have a mergeable series before you have to
stop to work on this?

You can only manage the case before the change reported by Arnd (I will
manage the new case myself later).


Hi, all.

Sorr= y for interjecting myself into this discussion, but I just want to let you = know about some related practicalities.

Filip is a= student that is from time to time (usually between two exam seasons) an in= tern in our company, working 4 hours each work day. He spent his internship= in different teams in prevous years, and, from around mid-October 2019, wa= s appointed to QEMU team. After some introductory tasks, he was assigned hi= s main task: linux-user support for RTCs and ALSA timers. This series is th= e result of his work, and, to my great pleasure, is virtually entirely his = independant work. I am positive he can complete the series by himself, even= in the light of additional complexities mentioned in this thread.

However, his exam season just started (Jan. 15th), and las= ts till Feb. 15th. Our policy, in general, is not to burden the students du= ring exam seasons, and that is why we can't expect prompt updates from = him for the time being.

In view of this, Laurent, = please take Filip's status into consideration. As far as mergeability i= s concerned, my impression is that patches 1-6 and 13 are ready for merging= , while patches 7-12 would require some additional (netlink-support-like) w= ork, that would unfortunately be possible only after Feb. 15th.
<= br>
Best wishes,
Aleksandar


Laurent, hi again.

<= /div>
I am not completely familiar with all details of Filip's work= , since, as I said, he had large degree of independance (which was intentio= nal, and is a desired and good thing IMHO), but taking a closer look, a que= stion starting lingering: Do we need special handling od read() even for RT= C devices - not only ALSA timer devices?

Best rega= rds,
Aleksandar
=C2=A0


Thanks,
Laurent


--000000000000d7d671059c401dc5--