Linux kernel updates and v6.0

[Joel Stanley]

On Wed, 5 Oct 2022 at 11:33, Patrick Williams <patrick at stwcx.xyz> wrote:
>
> Joel,
>
> Any thoughts on this?
>
> On Wed, Sep 28, 2022 at 03:30:23PM -0700, William Kennington wrote:
> > The ToF was talking about linux versions being used for OpenBMC users and

In the future it would be preferable to bring the discussion to the
community first, instead of talking among the TOFs.

> > we were wondering if we could codify a policy around which versions we will
> > be developing against regularly. In the past it seems like you usually pick
> > LTS releases to base on (and Facebook / Google are interested in sticking
> > with LTS releases in order to reduce toil / number of potentially
> > incompatible kernel upgrades for each of our machines). It would seem like
> > kernel 6.0 should be an LTS release, although gregkh hasn't said anything
> > specifically about it yet. Can we get something written about the expected
> > alignment with upstream kernel release cadence?

The documented alignment is every 30 days:

 https://github.com/openbmc/linux/wiki/DevelopmentProcess#openbmc-kernel-maintainer

Obviously that doesn't happen, because we lack the developer power to
perform this work. The document could do with some updates in that
respect.

I intend to rebase on each upstream release as they come out. This
means every 90 days or so. There was a period where that worked well,
but we have been stuck for a while due to lack of developer (my) time.

Building on an upstream LTS makes sense if the following are true:

 - You're regularly pulling in the stable point releases and pushing
them out as firmware updates

 - All of your patches are upstream. The stable tree can only apply
patches to code that is upstream. If they're not upstream, then
they're not getting patches backported to fix the issues, so the
stable tree doesn't provide any benefit to you

 - You're actively submitting fixes to mainline to be backported to stable

Obviously there's code that we ship on the BMC that is upstream, and
gets a lot of attention from the wider kernel community. The
networking code, filesystems, scheduler.

Given we have a lot of downstream code, I would (and regularly do)
argue that we're just as well off shipping the latest upstream kernel
than we are staying on an old LTS with less upstream code.

As we strive to upstream more of our code, the benefits of being on a
LTS tree increase.

How do we encourage developers to upstream their code? One way is to
regularly rebase on upstream releases, and drop patches that have not
seen any development. This works as a forcing function and incentive
for upstream development, and you could argue it has worked. Since
dropping PECI in v5.15 we have seen it submitted and merged upstream,
for example.

I've had minimal trouble moving the IBM systems from kernel release to
kernel release. Perhaps you're relying on userspace interfaces that
are not upstream? If that is the case, I encourage you to get the
interfaces upstream earlier, so moving is less effort.

Cheers,

Joel

> For minor clairification, I believe it was Intel / Google that preferred
> LTS.  Meta does not have a preference as long as the OpenBMC tree is
> well-supported and we can backport changes that have been sent
> upstream.