On Fri, Sep 13, 2024 at 01:53:41PM +0200, Pierre-Louis Bossart wrote:
On 9/13/24 12:59, Cezary Rojewski wrote:
Instead, I'd suggest to have a second, separate DPCM implementation present next to the existing one and have users opt in during a so- called deprecation period of the existing one. Once certain amount of time passes, switch all of them. Clean slide also makes it easier for a developer to be creative.
Do you view the second option as viable?
Classic problem without a good solution. In practice new features or corrections get added to the 'old' framework and the new one is not used by anyone just yet so it keeps running behind in terms of features/maturity. And due to limited validation resources or limited access to a wide variety of hardware, no one is quite ready to enable the new framework on 'old' platforms because that would break quite a few devices.
Yeah, there's no idea way of doing things here. I do think that keeping things going in parallel is probably the most viable way of doing things. You'd need at least one lead platform using the new stuff, and probably each platform would have a flag day to transition.
I'm a little more optimistic than Pierre about making progress, hopefully things would be sufficiently nicer that once there's something to build on it'd start to get more attractive to do the incremental investments needed in the core to enable more platforms, and reduced maintainance costs get more appealing. This approach has worked for other things (regmap springs to mind, and if you look at some of the way API transitions are done in the memory management and arch code there's a bunch of this going on) though it's rarely fast.
The other problem is that the 'switch' would mean a compatible solution, but the problem is to get rid of the very notion of front- and back-ends. Existing users of DPCM have undocumented hard-coded dependencies on the order in which callbacks are handled, it's not easy at all to change the routing engine.
Each platform is going to need to be pretty careful with the conversion and validating that things work. There are some simpler ones which will probably have an easier time of it, though. There's some of them like Kirkwood that are just at the lower end of needing DPCM support at all, and others that didn't upstream so much stuff yet so there's less knowledge embedded in the upstream code.