OpenBMC Linux 6.1

[Joel Stanley]

On Wed, 22 Feb 2023 at 06:11, Tao Ren <rentao.bupt at gmail.com> wrote:
>
> Hi Joel,
>
> Thanks for the update. Let me move some Meta/Facebook AST2500 and
> AST2600 Network OpenBMCs to v6.1, and will share my findings later.

Thanks Tao, I appreciate it.

> Besides, could you please share your long term kernel upgrade plan? For
> example, are you planning to align with LTS kernel in the future? Or the
> ultimate goal is to upgrade openbmc kernel whenever newer kernel is
> released?

Somewhere in between those two.

If we were to wait 5 or so years between updates, then we remove the
motivation for developers to upstream their code, and I imagine it
would be a headache to hunt down regressions when making that big
jump.

On the other hand, management has been trained to target the stable
releases and somehow consider them to be better than others. I argue
this isn't true, because the code is only as stable as the test and
development resources that are put into it! That said, it's less work
to merge in the stable tree every week or two and test that than it is
to do a new rebase every three months.

The ultimate goal is to have all of our code upstream, and just use
whatever kernel yocto has. We're pretty close for aspeed machines; at
IBM we have some downstream hacks for misbehaving i2c devices, and
some device trees for pre-production hardware that have minor
differences to the production version. If we were to upstream the
hacks for i2c devices (or stop using them) then we could ship upstream
kernels.

Ultimately it would be best for the project if we used the latest
kernel on master, and had a LTS kernel that was used by product
branches. This would require the project to fund someone to do this
work long term, to ensure the stable updates haven't caused
regressions, to cherry pick patches that fix code that was not present
in the upstream release, and in their remaining time help get more
code in mainline.

Cheers,

Joel