On Wed, Jun 14, 2023 at 11:16:19AM +0200, Takashi Iwai wrote:
On Wed, 14 Jun 2023 10:52:54 +0200, Oswald Buddenhagen wrote:
you're allowing _hypothetical_ crappy 3rd party code to dictate what you can and cannot do. that's a completely unreasonable and counterproductive attitude, akin to letting hostage-takers set the rules.
Oswald, it's no hypothetical, I have seen lots of applications that did crash with such mixer element changes in the past.
these apps have been meanwhile fixed or become obsolete, which makes it a hypothetical again.
It's no dictation by 3rd party.
it IS. that's exactly what letting downstream limit your possibilities is. especially if it's BROKEN downstream.
We simply must not crash things by an update (unless it's a must, something like a security fix).
and i'm telling you that this is an unreasonable reading of the rule. _every_ new feature in something already existing has the potential to blow up some crappy downstream code.
Oh well, that's really not a change to be advertised for creating / deleting kctls from the put callback at all. and? it's done, and it's basically impossible to revert. so we
may reap its full benefits just as well, as i did in that previous commit.
Well, I can revert your commit, too...
sure, but my point was that there are likely many more such commits, some of them not explicitly marked as such. it would be a very costly and risky exercise to actually do that revert at this point.
Sure, I didn't mean to do it immediately, it's no easy task.
great! then you can adjust this driver at that later point as well, when you actually want to go forward with that project. ;-)
The way you're trying to implement is an anti-pattern,
that's something you keep repeating in various ways, but i see no evidence that there is an _actual_ problem.
There were actual problems, and we had to address them.
what exactly where those problems? do the circumstances under which they occurred still apply?
The API is there and it should be usable in the ideal world, but we know that it breaks far more than expected. We don't prohibit that API, but the actual use should be limited for very special use cases.
that's exactly the wrong way to go about it. the way to make sure that fewer apps crash is to hammer them as much as possible. if you wanted to make sure that they all *really* work, you'd randomly create and destroy fake controls from time to time.
If it were triggered in only certain (rare and race-free) situations, it'd be acceptable. But your patch allows every user to trigger it by the normal kctl value adjustment, which is simply no-go.
you are describing a completely contrieved attack scenario. it would have to be a multi-user system with an e-mu card where one user intentionally messes with the mixer to crash a broken application another user is using at the same time. think through the probabilities, motivations, alternative attack vectors, and how the whole affair would play out IRL for the attacker.
regards, ossi