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 Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 25EA4EB64D0 for ; Tue, 13 Jun 2023 14:01:37 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id A55A9E7D; Tue, 13 Jun 2023 16:00:44 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz A55A9E7D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1686664894; bh=YIdLKZnfzAhjAe4b0LpxcSl3iM43h5xSxLuurmdK4+M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-Id: List-Archive:List-Help:List-Owner:List-Post:List-Subscribe: List-Unsubscribe:From; b=Qd/Ed3LbQ6GH4cWNFrpaAjq86VV8iF0rroUoyT8ScD7sMrnVaPSbGfiKudhW8Kadt 0rEpxnkv8O6kjDpYbGldKAgfGcmFKeyK64fXaN/blDBuQm0yYGqtUa8Io60NPCmDO0 jOc5/Ibh2RGREh3pFYDDM6sxa3L4jACIboT7zRkY= Received: by alsa1.perex.cz (Postfix, from userid 50401) id 2CBA6F8052E; Tue, 13 Jun 2023 16:00:43 +0200 (CEST) Received: from mailman-core.alsa-project.org (mailman-core.alsa-project.org [10.254.200.10]) by alsa1.perex.cz (Postfix) with ESMTP id 99FE2F80149; Tue, 13 Jun 2023 16:00:43 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id AEC36F80149; Tue, 13 Jun 2023 16:00:39 +0200 (CEST) Received: from bluemchen.kde.org (bluemchen.kde.org [IPv6:2001:470:142:8::100]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id EFB11F80130 for ; Tue, 13 Jun 2023 16:00:36 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz EFB11F80130 Received: from ugly.fritz.box (localhost [127.0.0.1]) by bluemchen.kde.org (Postfix) with ESMTP id 15BF824129; Tue, 13 Jun 2023 10:00:35 -0400 (EDT) Received: by ugly.fritz.box (masqmail 0.3.4, from userid 1000) id 1q94ZW-imm-00; Tue, 13 Jun 2023 16:00:34 +0200 Date: Tue, 13 Jun 2023 16:00:34 +0200 From: Oswald Buddenhagen To: Takashi Iwai Cc: alsa-devel@alsa-project.org, Jaroslav Kysela Subject: Re: [PATCH 6/8] ALSA: emu10k1: add support for 2x/4x word clocks in E-MU D.A.S. mode Message-ID: References: <20230613073822.1343234-1-oswald.buddenhagen@gmx.de> <20230613073822.1343234-7-oswald.buddenhagen@gmx.de> <87v8fren1k.wl-tiwai@suse.de> <87edmfei0o.wl-tiwai@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <87edmfei0o.wl-tiwai@suse.de> Message-ID-Hash: ETDACMYWYN3NCALKPOWGPBCYIMFYQ34C X-Message-ID-Hash: ETDACMYWYN3NCALKPOWGPBCYIMFYQ34C X-MailFrom: ossi@kde.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-alsa-devel.alsa-project.org-0; header-match-alsa-devel.alsa-project.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.8 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Tue, Jun 13, 2023 at 01:08:55PM +0200, Takashi Iwai wrote: >On Tue, 13 Jun 2023 12:52:43 +0200, >Oswald Buddenhagen wrote: >> >> On Tue, Jun 13, 2023 at 11:20:23AM +0200, Takashi Iwai wrote: >> > Creating and removing the controls from kctl put callback is no >> > good >> > idea. In general, dynamic control creation/deletion already confuses >> > user-space. >> > >> i kind of expected that, but what i've tried so far worked remarkably >> well (ok, it was mostly alsamixer). >> >> > On top of that, if it's done by a control element, it can >> > be even triggered endlessly by user. >> > >> it shouldn't, because there is no circularity between the >> controls. even if the app sets all controls as a response to new ones >> appearing, the second round will be a no-op for the multiplier >> control, and therefore causes no new creation/deletion notifications, >> and thus terminates the recursion. > >Hmm I don't get it; if an application just toggles the kctl value >between two values in an infinite loop, it'll delete and recreate >kctls endlessly as well with your patch, no? > yeah, but why should it toggle just so? it's not reasonable to do that. and if we assume it's being unreasonable, then there is no reason to think that controls appearing and disappearing would be special. >> also, i don't think that disabling would be fundamentally different >> from deleting: the particular code paths taken are somewhat different, >> but the high-level view is essentially the same. so we can't really >> make predictions which one would work better. > >Creating and deleting needs a lot of different works and much heavier >tasks. > it's entirely plausible that an application would tear down structures in response to controls being disabled, too. >And, above all, many user-space programs will be borked if an >element goes away, simply crashing. Some (rather rare) nice ones will >still survive, though. I've learned this from the past. > yeah, but why should we care? it's not a regression when something new doesn't work with some crappy pre-existing code. >> > And, if we really have to create / delete a kctl element from some >> > kctl action, don't do it in the callback but process in another work. >> > >> would that really improve anything? > >As a primary reason, I don't want to expose such a stuff. If you need >such an unlocked version, you're already doing something very exotic, >and in 99% cases, it's something that needs more care. > i don't see being "exotic" as something to avoid per se. and before putting in "more care" i want to see some evidence that there is actually a problem that needs to be addressed, in this place. esp. when the proposed much more complex alternative hasn't been shown to be actually better in relevant ways, even theoretically. regards, ossi