Resolve Rockchip patch maintenance nightmare
Description
Checklist
hideActivity
jock January 24, 2024 at 8:54 PM
Oh ok, I forgot to the associated merge request. Ok I guess we will go ahead later opening more Jira tasks when appropriate (I guess very soon rockpi-s legacy patch archive could be removed at least…)
I close it again and sorry for the chaos!
Gunjan Gupta January 24, 2024 at 8:38 PM
ok.. moved it back to previous status. Igor asked me to close it as there is a closed merge request during Weekly meeting.
jock January 24, 2024 at 8:29 PM
well, this is not exactly completed since there is still a discussion in progress, despite it has being slowed down recently. There still are the legacy archives to remove and let the ideas be mature enough to move on.
jock December 15, 2023 at 10:30 PM
rockchip-legacy and rk322x-legacy can be deprecated and/or removed if necessary. I can hazard to say that perhaps rk322x and rockchip 32 bit families could be merged, but that would require an amount of work and rockchip 32 bit should change its boot process with the presence of a Trust OS.
Things that are higher priority IMHO:
I don’t know who uses rk3399-legacy, but that should be indeed deprecated and interesting bits merged into rockchip64-legacy, although I don’t know if it is sensible to keep rockchip64-legacy
rockpis-legacy also is not expected to be there and should be perhaps merged into rockchip64-legacy too; it is even not a family but a subset of boards and should have never appeared in that form.
Some thoughts come to my mind about support for newer socs: they often require a vendor kernel and not a “legacy” kernel. Also, sometimes different socs from the same vendor may require a different kernel version. We should define a strategy for those kind of new socs that only work on vendor kernel until they don’t get mainlined, but rules with vendor kernel should be strict IMHO. for example a vendor kernel:
can support only one soc
must not receive patches for other socs or for board using other socs
must live until the soc is not enough supported in mainline
So, to say an example, we would end up with these rockchip64 kernels:
rockchip64-current
rockchip64-edge
vendor-rk356x
vendor-rk3588
rockchip64-current and edge would support rk3328, rk3399, rk3368. rk356x and rk3588 would be supported as best as possible
vendor-rk356x would provide vendor kernel and patches only for rk356x for the time necessary the support in mainline would be mature enough
vendor-rk3588 would provide vendor kernel and patches only for rk3588 as well
We have way too many Rockchip branches (for too long), too many patch folder. A recipe for getting insane on a long run. This is already unmaintainable while many older boards works almost fine with a generic arm64 kernel. We don’t need to go that far, but lets deal with this black hole before it eats us.
Before (not to mention all the archive, which should also be removed):
After:
Branches:
rockchip64-current rockchip64-edge rockchip64-legacy rockchip-current rockchip-edge rockchip-legacy/Please propose how we could slice this down that transition become manageable. What can/will break and where we can compromise? If you can do something to minimize this, open a sub-task and do it when you can. Every removal will helps us all.