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
