Linux, Open Source & Unrelated Topics - yoctohttps://pbarker.dev/2023-12-27T00:00:00+00:00meta-linux-mainline in 20232023-12-27T00:00:00+00:002023-12-27T00:00:00+00:00Paul Barkertag:pbarker.dev,2023-12-27:/posts/2023-12-27/meta-linux-mainline-in-2023/<p class="first last">It's time for a year end review of <a class="reference external" href="https://github.com/betafive/meta-linux-mainline">meta-linux-mainline</a>, a <a class="reference external" href="https://www.yoctoproject.org">Yocto Project</a> layer which contains recipes for all
currently supported Linux kernel release series and the latest mainline
kernel. This year the project has seen various improvements as well as the
regular flow of new Linux kernel & Yocto Project releases. The layer is now
updated most weeks, more closely tracking the kernel release cycle but
there's still more we can do with additional resources.</p>
<!-- Copyright (c) 2023 Paul Barker <paul@pbarker.dev>
SPDX-License-Identifier: CC-BY-NC-4.0 -->
<p>I maintain <a class="reference external" href="https://github.com/betafive/meta-linux-mainline">meta-linux-mainline</a>, a <a class="reference external" href="https://www.yoctoproject.org">Yocto Project</a> layer which contains recipes for all currently
supported Linux kernel release series and the latest mainline kernel (see
<a class="reference external" href="https://kernel.org">kernel.org</a> for the current list). This is a side
project for me, but it has seen usage in both my current day job with Renesas
and my previous work with SanCloud.</p>
<p>This year the project has seen various improvements as well as the regular flow
of new Linux kernel & Yocto Project releases. The layer is now updated most
weeks, more closely tracking the kernel release cycle but there's still more we
can do with additional resources.</p>
<p>I'll be taking a break from updating meta-linux-mainline over the holidays -
there will be no update over the Christmas or New Year weeks, regular updates
will resume from the week of Monday 8th January 2024.</p>
<div class="section" id="a-quick-introduction-on-use-cases">
<h2>A quick introduction on use cases</h2>
<p>If you're not familiar with meta-linux-mainline, the goal of this project is to
complement the work on the Yocto Project reference kernel (linux-yocto), rather
than to compete with it. I recommend looking at meta-linux-mainline for the
following use cases:</p>
<ul class="simple">
<li>You need to closely track the latest mainline kernel, including release
candidates, without any downstream patches. This can be vital when preparing
patches to send upstream, trying to report bugs to the kernel development
community and testing to ensure that your product will be fully supported in
future kernel releases.</li>
<li>You need to stay on an older LTS kernel series while moving to a more recent
Yocto Project release.</li>
<li>Conversely, you need to use a newer kernel series while staying on an older
(but still supported) Yocto Project release.</li>
</ul>
<p>For other use cases I recommend looking at the linux-yocto recipes in the
openembedded-core layer or the appropriate vendor kernel recipes in the BSP
layer for your target machine.</p>
</div>
<div class="section" id="funding">
<h2>Funding</h2>
<p>My work on meta-linux-mainline is unpaid, and this year I invested in
updating my development machine (now using a Ryzen 7 7700 CPU, 64GB RAM and 2TB
gen4 NVMe storage) so that the full matrix of 216 Yocto Project builds (4
supported Yocto Project releases x 6 qemu machine targets x 9 supported kernel
series) can complete in a reasonable time.</p>
<p>I'd like to setup a proper CI loop for meta-linux-mainline, but this will
require renting a build machine in a data center (at a cost of around €59.00 per
month if I use Hetzner) as the free runners provided with GitHub Actions don't
have enough storage or compute power for full Yocto Project builds and I can't
setup a GitHub Actions runner on my development machine at home for security
reasons.</p>
<p>I'd also like to do boot testing with each image we build, at least in qemu, but
that would further increase the build and test time for each update to the
layer. Given sufficient interest and financial support, we could extend the
build matrix to include real development boards (not just qemu machines) and
setup a board farm using labgrid to boot test each image we build.</p>
<p>I currently try to keep a fairly light time commitment on meta-linux-mainline.
The layer gets updated most weeks using the automated <tt class="docutils literal"><span class="pre">update-layer</span></tt> script,
but if anything fails to build I may not be able to address this immediately.
I've recently sent
<a class="reference external" href="https://lore.kernel.org/stable/20231031172217.27147-1-paul.barker.ct@bp.renesas.com/">a</a>
<a class="reference external" href="https://lore.kernel.org/stable/20231031173255.28666-1-paul.barker.ct@bp.renesas.com/">few</a>
<a class="reference external" href="https://lore.kernel.org/stable/20231031173501.28992-1-paul.barker.ct@bp.renesas.com/">backport</a>
<a class="reference external" href="https://lore.kernel.org/stable/20231031173524.29161-1-paul.barker.ct@bp.renesas.com/">requests</a>
for the stable kernel (based on fixes in mainline from other contributors), but
I'd like to be able to do more.</p>
<p>I'm happy to continue work on meta-linux-mainline in its current form without
any external funding, but if you'd like to see the project grow then more
resources will be needed. If you use this layer, please consider supporting
ongoing development via <a class="reference external" href="https://ko-fi.com/pbarker">Ko-fi</a> or <a class="reference external" href="https://paypal.me/betafiveltd">PayPal</a>. Alternatively, please <a class="reference external" href="mailto:paul@betafive.dev">send me an email</a> if you'd like to discuss a more formal
business-to-business agreement for consulting or sponsorship of this development
work.</p>
</div>
<div class="section" id="a-url-change">
<h2>A URL change</h2>
<p>The meta-linux-mainline git repository was recently moved to
<a class="reference external" href="https://github.com/betafive/meta-linux-mainline">https://github.com/betafive/meta-linux-mainline</a> as part of a plan to
consolidate my projects under the Beta Five company name. A redirect from the
old URL will be maintained indefinitely so hopefully this change won't cause any
disruption.</p>
</div>
<div class="section" id="keeping-it-building">
<h2>Keeping it building</h2>
<p>This year saw two new Yocto Project releases,
<a class="reference external" href="https://docs.yoctoproject.org/migration-guides/release-4.2.html">4.2 "mickledore"</a> and
<a class="reference external" href="https://docs.yoctoproject.org/migration-guides/release-4.3.html">4.3 "nanbield"</a>.
The meta-linux-mainline layer was updated to support each new release as they
came out. Support for the "mickledore" release has now been dropped as it is
end-of-life.</p>
<p>At the beginning of 2023 the meta-linux-mainline layer was still advertising
compatibility with the "gatesgarth", "hardknott", "honister" and "langdale"
Yocto Project releases via the <tt class="docutils literal">layer.conf</tt> file. These have all now been
dropped as they are obsolete and no longer supported upstream.</p>
<p>Next year will see both the "nanbield" release and the old LTS "dunfell" release
reach end-of-life. In their place we'll have a new LTS release in April
(tentatively called 5.0 "scarthgap") and a regular release in October/November
(as yet unnamed).</p>
<p>As we've moved to newer Yocto Project releases, minor updates were needed to the
<tt class="docutils literal">LICENSE</tt> reference in the kernel recipes to align with the current SPDX
license naming.</p>
<p>The autobuild infrastructure for meta-linux-mainline has been overhauled this
year to improve build reliability and simplify maintenance. We're now using
the <a class="reference external" href="https://kas.readthedocs.io/en/latest/">kas</a> wrapper to fetch layers,
write configuration files and invoke bitbake for our test builds.</p>
<div class="section" id="side-note-adding-meta-linux-mainline-to-your-build">
<h3>Side note: Adding meta-linux-mainline to your build</h3>
<p>Provided that you're using a currently supported Yocto Project release series,
it's very simple to add the meta-linux-mainline layer to your build. Once
your build environment has been initialised, run the following command:</p>
<pre class="literal-block">
bitbake-layers layerindex-fetch meta-linux-mainline
</pre>
<p>If this all sounds interesting, but you're unfamiliar with the Yocto Project, I
recommend starting with the <a class="reference external" href="https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html">Quick Build guide</a>.</p>
</div>
</div>
<div class="section" id="reference-machines">
<h2>Reference machines</h2>
<p>This year I dropped the Raspberry Pi 4 (both 32-bit & 64-bit modes) from the
build matrix for meta-linux-mainline, giving me room to include <tt class="docutils literal">qemuriscv32</tt>
and <tt class="docutils literal">qemuriscv64</tt> to the matrix instead. With strong interest in RISC-V across
the industry, it's important to ensure that this architecture is supported. To
avoid excessive integration work, RISC-V support is only tested for Linux v5.15
or later and Yocto Project 4.0 "Kirkstone" or later.</p>
<p>Since we're building vanilla kernels using the in-tree <tt class="docutils literal">defconfig</tt>
configuration, there isn't really any difference between a <tt class="docutils literal">qemuarm</tt> (or
<tt class="docutils literal">qemuarm64</tt>) kernel build and a <tt class="docutils literal">raspberrypi4</tt> (or <tt class="docutils literal"><span class="pre">raspberrypi4-64</span></tt>)
kernel build with meta-linux-mainline. To support booting on the Raspberry Pi,
we do need some additional integration to select an appropriate device tree,
configure the bootloader for booting an upstream kernel and drop features which
aren't yet supported with an upstream kernel. This integration remains in the
meta-linux-mainline layer, and can be enabled by including
<tt class="docutils literal"><span class="pre">conf/linux-mainline/bsp/raspberrypi4.inc</span></tt> or
<tt class="docutils literal"><span class="pre">conf/linux-mainline/bsp/raspberrypi4-64.inc</span></tt> as needed in your <tt class="docutils literal">local.conf</tt>
file, but it is no longer built regularly and so may be subject to some bitrot.
I'd like to restore this support fully in the future, with automated boot
testing on real hardware, but that's definitely going to need some funding as
outlined above.</p>
<div class="section" id="side-note-bsp-configuration-in-meta-linux-mainline">
<h3>Side note: BSP configuration in meta-linux-mainline</h3>
<p>The recommended way to configure meta-linux-mainline for a particular
<tt class="docutils literal">MACHINE</tt> is to use a <tt class="docutils literal">.inc</tt> file under the <tt class="docutils literal"><span class="pre">conf/linux-mainline/bsp</span></tt>
directory, with the filename matching the machine name (e.g. <tt class="docutils literal">qemuarm.inc</tt> for
the <tt class="docutils literal">MACHINE = "qemuarm"</tt>). For the supported QEMU targets and the Raspberry
Pi 4, these files already exist in the layer itself. For other target machines,
we suggest that you create these files in the appropriate BSP layer or in a
separate integration layer.</p>
<p>This then allows you to enable meta-linux-mainline integration by adding the
following to your <tt class="docutils literal">local.conf</tt> file or distro configuration:</p>
<pre class="literal-block">
require conf/linux-mainline/bsp/${MACHINE}.inc
</pre>
</div>
</div>
<div class="section" id="kernels-old-and-new">
<h2>Kernels old and new</h2>
<p>The default LTS kernel in meta-linux-mainline has changed twice this year - back
in March the layer was updated to use the v6.1 LTS series, then in November it
was announced that <a class="reference external" href="https://www.phoronix.com/news/Linux-6.6-Goes-LTS">v6.6 would be the new LTS series</a> and the layer was updated
again.</p>
<p>The new LTS series will be maintained until December 2026, meaning that
the end-of-life for the last 4 LTS series are all aligned. The support period
for LTS kernels is slowly reducing in line with the announcement earlier in the
year, it's expected that future LTS series will be supported for 2 years each.
This will definitely reduce the number of kernel recipes in meta-linux-mainline
over the next couple of years and should make maintaining this layer a little
easier.</p>
<p>On the subject of old LTS series, the recipe for the 4.9 series was dropped
early this year as it reached EOL. Next year it's expected that we'll be
dropping the recipe for v4.14 after it goes EOL in January, and then v4.19 after
it goes EOL in December.</p>
<div class="section" id="side-note-following-a-kernel-series-in-your-build">
<h3>Side note: Following a kernel series in your build</h3>
<p>To follow the latest mainline kernel from Linus (including release candidates)
using this layer, you can add the following to your <tt class="docutils literal">local.conf</tt> file or
distro configuration:</p>
<pre class="literal-block">
require conf/linux-mainline/mainline.inc
</pre>
<p>If you don't want to track the bleeding edge of development, you can instead use
the following to get the latest stable release from Greg K-H and move to a new
stable series every 9 or so weeks:</p>
<pre class="literal-block">
require conf/linux-mainline/stable.inc
</pre>
<p>To follow the latest LTS kernel series and move to a new LTS series each year,
you can use the following:</p>
<pre class="literal-block">
require conf/linux-mainline/lts.inc
</pre>
<p>And lastly, if you want to stay on a particular LTS series for the long haul,
for example v6.1, you can add the following instead (replacing <tt class="docutils literal">6.1</tt> with
whichever LTS series you want to track):</p>
<pre class="literal-block">
require conf/linux-mainline/stable.inc
PREFERRED_VERSION_linux-stable = "6.1%"
</pre>
</div>
</div>
A decade of contribution to OpenEmbedded & the Yocto Project2023-05-11T00:00:00+00:002023-05-11T00:00:00+00:00Paul Barkertag:pbarker.dev,2023-05-11:/posts/2023-05-11/a-decade-of-contribution-to-openembedded-the-yocto-project/<p class="first last">I realised recently that I have now been involved in OpenEmbedded and the
Yocto Project for over a decade! I thought I'd take the opportunity to look
back at how I first got involved with the project and my early
contributions.</p>
<!-- Copyright (c) 2023 Paul Barker <paul@pbarker.dev>
SPDX-License-Identifier: CC-BY-NC-4.0 -->
<p>Back in 2013, I was a research student at Loughborough University working on an
underwater acoustic recording platform, the UDAQ, based around the <a class="reference external" href="https://beagleboard.org/beagleboard-xm">BeagleBoard
xM</a> Single Board Computer. I had built a daughterboard for this platform which
connected a Texas Instruments ADS1672 ADC to the Multi-channel Buffered Serial
Port (McBSP) of the AM37x processor on the BeagleBoard xM, and I had started
work on a Linux kernel driver for this Analog-to-Digital Converter (ADC) which
could be loaded as a module. What I needed next was to configure the pin
multiplexing (pinmux) on the processor to enable the McBSP. As this was in the
Bad Old Days™ before device trees were universal <a class="footnote-reference" href="#footnote-1" id="footnote-reference-1">[1]</a>, to do this I had to
modify a board file in the Linux kernel source tree and rebuild the whole
kernel.</p>
<p>The software image for the BeagleBone xM used the <a class="reference external" href="https://en.wikipedia.org/wiki/%C3%85ngstr%C3%B6m_distribution">Ångström Linux
distribution</a>. This image was written to an SD card which was then inserted
into the BeagleBoard xM. Once the system was booted you could connect over a
serial port and make normal use of the Linux command line. Additional packages
could be installed via the opkg package manager, with the Ångström distribution
providing a feed of pre-built binary packages via their website. But what if you
wanted to rebuild a software package such as the Linux kernel, or to build and
install your own custom software packages? This is what I needed to do, but the
system performance and the space available on an SD card in 2013 really didn't
lend themselves to building software on the BeagleBone xM itself.</p>
<p>Enter the <a class="reference external" href="https://www.openembedded.org/wiki/Main_Page">OpenEmbedded</a> build system, and the Linux Foundation's <a class="reference external" href="https://www.yoctoproject.org/">Yocto
Project</a> collaboration built around it. The Ångström distribution was not
compiled on the BeagleBoard xM itself, instead it was cross-compiled on a more
powerful desktop or server computer using the Yocto Project. I realised that I
did not have to settle for minor additions to the Ångström distribution and a
rebuilt kernel - using Yocto Project I could build a completely custom software
image for the UDAQ device. This was a huge boon for the project I was working on
as a tightly controlled software environment with minimal background services
running would increase the reliability when trying to capture and analyse
acoustic data in real time. With luck it would also increase the battery life of
the device, although I didn't actually test that in the end.</p>
<p>So, I set up a build environment on my desktop PC and I jumped into version 1.4
of the Yocto Project, codenamed "Dylan". I remember there being a lot to learn,
but I also remember quickly making progress. As I've often done, I learned my
way around Yocto Project by experimenting and by seeing if I could fix issues as
I came across them. After a couple of early attempts on the mailing list, I
landed my first contribution in March 2013: <a class="reference external" href="https://git.yoctoproject.org/poky/commit/?id=d12980ff1d47df0b6b8c10c595779af16cb76ffa">a one-line fix for the gnupg recipe</a>.</p>
<div class="figure">
<img alt="" src="https://pub.pbarker.dev/photos/misc/udaq1.webp" style="width: 100%;" />
<p class="caption">An early prototype of the UDAQ hardware. From left to right, you can see the
end cap of the UDAQ housing, the signal amplification & conditioning board,
and the BeagleBoard xM. This version lacked the ADS1672 ADC and used the
audio line input to the BeagleBoard xM to digitise the signals from a
hydrophone, limiting the bandwidth which could be captured.</p>
</div>
<div class="figure">
<img alt="" src="https://pub.pbarker.dev/photos/misc/udaq2.webp" style="width: 100%;" />
<p class="caption">A later prototype of the UDAQ hardware (in glorious potato-camera quality).
From top to bottom, this PCB stack consists on an ADS1672 evaluation module,
a custom interposer board which I designed, and the BeagleBoard xM.</p>
</div>
<p>In June of 2013 I began to organise the software for the UDAQ project into git
repositories (I think I was using Subversion before this) and push them to
BitBucket. These repositories are still online today, though managing them is no
longer possible due to changes Atlassian has made to BitBucket in recent years <a class="footnote-reference" href="#footnote-2" id="footnote-reference-2">[2]</a>.
I also don't trust that they'll always remain available on BitBucket, so I've
copied the code over to GitHub to make it more available:</p>
<ul class="simple">
<li><a class="reference external" href="https://github.com/unnecessary-abstraction/tuna">tuna</a>: Toolkit for Underwater Noise Analysis, the user space service used to
record and analyse data on the UDAQ.</li>
<li><a class="reference external" href="https://github.com/unnecessary-abstraction/ads1672">ads1672</a>: The driver for the TI ADS1672 ADC.</li>
<li><a class="reference external" href="https://github.com/unnecessary-abstraction/meta-udaq">meta-udaq</a>: The Yocto Project BSP and distro layer for the UDAQ.</li>
<li><a class="reference external" href="https://github.com/unnecessary-abstraction/udaq-build">udaq-build</a>: Build configuration and scripting.</li>
</ul>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">This code is obsolete and only of historical interest now, most of it won't
build.</p>
</div>
<p>In parallel to my work on the UDAQ, I continued contributing to Yocto Project.
After attempting to get a couple of bugfixes applied to the opkg package
manager, I was given commit access to the source repository for this tool in
August 2013. The first thing I did was commit someone else's bugfix patch for an
issue which I felt was more urgent than my own. I then had a sudden "oh shit"
moment when I realised that committing code from another contributor effectively
made me a maintainer of opkg. Two weeks later I cut a release candidate and in
September 2013 I made my first release as the new opkg maintainer (<tt class="docutils literal">v0.2.0</tt>).
I continued maintaining opkg until 2015 when I became too busy with my new job
at CommAgility to devote much time to opkg.</p>
<p>I consider my work on opkg to have been a huge success - I took a project which
was struggling, was weighed down by technical debt and was difficult to
contribute to and I passed it on to the next maintainer in a much cleaner state.
My biggest achievement here was removing legacy code and replacing it with a
dependency on a well maintained external library which implemented the functions
we needed - for a small cost in binary size we closed many of the open issues
and made ongoing work on opkg much less painful.</p>
<p>Another thing I remember well from my early years with Yocto Project was my
first visit to FOSDEM in January 2014. I met a few people at the OpenEmbedded
stand and this was my first opportunity to put faces to some of the names I'd
been talking to on the mailing list for several months. Everyone I met was
incredibly welcoming and encouraging and I think it has been this community of
contributors from various organisations which has kept me contributing and
coming back to the project ever since.</p>
<p>At FOSDEM 2014 I also gave my first presentation to an open source conference,
titled "Underwater Acoustics to Opkg, via The Yocto Project". I couldn't find
the video of this talk on YouTube so I have extracted it from the FOSDEM video
archives and uploaded it to YouTube for your viewing pleasure.</p>
<div class="youtube youtube-16x9"><iframe src="https://www.youtube.com/embed/QzsFphJACYc" allowfullscreen seamless frameBorder="0"></iframe></div><p>My contributions to Yocto Project have waxed and waned over the years, depending
on how busy I have been and on where my focus has been. Even during the times I
haven't been making regular upstream contributions of any significance I have
been using Yocto Project extensively in my day-to-day work. At this point, it's
a critical part of my Embedded Linux toolkit and I don't expect it to go away
any time soon!</p>
<p class="rubric">Footnotes</p>
<table class="docutils footnote" frame="void" id="footnote-1" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#footnote-reference-1">[1]</a></td><td>In these halcyon days, life is much easier. To change pinmux settings you
can rebuild just the device tree which is loaded by the kernel at runtime,
rather than having to rebuild the whole kernel.</td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="footnote-2" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#footnote-reference-2">[2]</a></td><td>All BitBucket repositories are now organised into "workspaces", but
these repositories pre-date the workspaces feature of BitBucket. They aren't
listed anywhere in the web interface after I've logged in and the only way
to find them is to navigate directly to the repository URL. Let this serve
as a warning - repositories stored on third-party hosting services can and
do break over time. Always keep backups!</td></tr>
</tbody>
</table>
Rebooting meta-linux-mainline2021-06-22T00:00:00+00:002021-06-22T00:00:00+00:00Paul Barkertag:pbarker.dev,2021-06-22:/posts/2021-06-22/rebooting-meta-linux-mainline/<p class="first last"><a class="reference external" href="https://github.com/unnecessary-abstraction/meta-linux-mainline">meta-linux-mainline</a>
is a Yocto Project layer I created in May 2020 when I needed to test a
few hardware boards with unpatched, upstream kernel sources. The
project has undergone a few changes recently so now is a good time to
give an updated overview of how the layer works and when you might
want to use it.</p>
<!-- Copyright (c) 2021 Paul Barker <paul@pbarker.dev>
SPDX-License-Identifier: CC-BY-NC-4.0 -->
<div class="section" id="introduction">
<h2>Introduction</h2>
<p>The meta-linux-mainline Yocto Project layer contains recipes for building the
Linux kernel from unmodified sources as released on kernel.org. It can be used
to develop a BSP which uses a mainline kernel by default, to replace the default
vendor kernel in an existing BSP (which may be obsolete, insecure or otherwise
broken), to support upstream kernel development or simply for testing. It
provides <tt class="docutils literal"><span class="pre">linux-stable</span></tt> recipes for all stable release series (including LTS
releases) currently supported upstream as well as a <tt class="docutils literal"><span class="pre">linux-mainline</span></tt> recipe
for those who want to live on the bleeding edge. It is compatible with all
currently supported Yocto Project releases ("dunfell" and "hardknott" at the
time of this post) as well as the Yocto Project master branch. Further details
can be found in the project's <a class="reference external" href="https://github.com/unnecessary-abstraction/meta-linux-mainline/blob/main/README.md">readme file</a>.</p>
</div>
<div class="section" id="use-cases">
<h2>Use Cases</h2>
<p>The meta-linux-mainline layer has two primary use cases: supporting the
development of new BSPs which use upstream kernel sources by default and
overriding the kernel recipes in existing BSPs to use upstream kernel sources
instead of vendor kernel sources.</p>
<p>When developing a new Yocto Project BSP for a hardware platform supported by the
mainline kernel, it should not be necessary to maintain your own mainline kernel
recipe. Users should be given the option of using the latest stable kernel, an
LTS release series or even a bleeding-edge mainline kernel without the BSP
maintainer needing to implement all these options. Users should also get regular
updates to the kernel recipes without needing to distract the maintainer from
focusing on the hardware-specific details of their BSP. These objectives can be
achieved by using meta-linux-mainline as a dependency of the BSP layer and where
necessary specifying the earliest mainline kernel version required to support
the target hardware.</p>
<p>Many existing BSPs default to the use of a "vendor kernel" which incorporates
many (sometimes several thousand) patches which have not been subject to
upstream review, testing and integration by the kernel community. In many cases
the target hardware is supported well enough by the mainline kernel for the
intended use-case without the need for such patching. This can be particularly
frustrating when the vendor kernel in question is obsolete, doesn't receive
security updates or introduces compatibility issues. To switch away from a
vendor kernel, the meta-linux-mainline layer can be added to the build alongside
the relevant BSP layer(s) and the relevant upstream kernel can be selected in
the local or distro config.</p>
<p>In both of these cases the linux-yocto recipes present in the core Yocto Project
metadata could be used instead of the recipes in meta-linux-mainline. However,
linux-yocto recipes are typically provided for a narrower set of kernel releases
than those currently supported upstream and recipes are not added to stable
Yocto Project branches for newer kernel release series (as the kernel community
places an incredibly high value on backwards compatibility it is generally safe
to update to new stable kernel releases). The linux-yocto kernels also include
many patches which may not have been through a full upstream review by the
kernel community. Using unpatched upstream kernel sources also has major
benefits when supporting multiple Linux distributions on the target hardware as
it is then possible to standardise on the upstream kernel. Lastly, if you have
customer requirements or preferences for a mainline kernel then these can be met
using the meta-linux-mainline layer.</p>
<p>This layer also supports two other secondary use cases. The mainline kernel
recipe provided in this layer can be used to support upstream kernel development
as it can be easily modified to point to an alternative source repository and
branch or commit. The recipes may also be used as part of a regular testing
process to ensure that an embedded device works as expected with new upstream
kernel releases.</p>
</div>
<div class="section" id="defining-goals-and-non-goals">
<h2>Defining Goals and non-Goals</h2>
<p>For a project like meta-linux-mainline to succeed, it needs a clearly defined
set of goals and non-goals. Goals identify the features and attributes which I
want to see in this project, non-goals identify things which may in theory be
possible to achieve but which I have chosen to exclude from the scope of this
project and which will not be implemented or accepted as contributions without a
major change to the project's scope. The goals are obviously important, they
should be aligned with the intended use cases for the layer and drive the
project forwards. The non-goals for a project are often overlooked but I think
they are equally important, they help the project to avoid bloat and stay on
track. Potential contributors can review the project's goals and non-goals and
find out upfront if their changes are likely to be accepted into the project.
The goals and non-goals for meta-linux-mainline are listed prominently in the
project's <a class="reference external" href="https://github.com/unnecessary-abstraction/meta-linux-mainline/blob/main/README.md#goals-and-non-goals-of-this-layer">readme</a>
file.</p>
<p>The current goals for meta-linux-mainline are as follows:</p>
<ul class="simple">
<li>We provide recipes for all Linux kernel releases currently supported on
kernel.org. These recipes are regularly updated to make it easy to follow
mainline releases, the latest stable series or a chosen LTS release series.</li>
<li>We aim to be compatible with all currently supported Yocto Project releases as
well as the upstream master branch.</li>
<li>We provide examples of how to use this layer in the form of BSP configurations
for various QEMU and Raspberry Pi targets.</li>
</ul>
<p>The current non-goals for meta-linux-mainline are as follows:</p>
<ul class="simple">
<li>We do not carry patches against upstream kernel releases without a documented,
exceptionally good reason.</li>
<li>We do not support obsolete kernel versions. Recipes are only provided for the
latest patch release within a given release series. Once a release series
becomes End-Of-Life (EOL) on kernel.org, the corresponding recipe will be
removed from this layer.</li>
<li>We provide no guarantees that kernels built with this layer will boot
successfully on your hardware or that particular features (e.g. perf) will
work out of the box. The example BSP configurations are not intended to be
directly used in production. To use this layer in production, create your own
layer for configuration & integration and use this layer as a dependency.</li>
<li>We do not aim to replace the linux-yocto kernel from the Yocto Project.</li>
</ul>
</div>
<div class="section" id="recent-changes">
<h2>Recent Changes</h2>
<p>Project maintenance is now focused on a single main branch which aims to be
compatible with the master branch and all currently maintained releases of the
Yocto Project. The "master" and stable branches ("dunfell", etc) of
meta-linux-mainline will simply follow the "main" branch. This simplification,
along with improved automation of updates to the kernel recipes, should result
in more regular updates to this layer while ensuring that the level of
maintainer effort required remains small and sustainable.</p>
<p>Several other changes have been made to the project as highlighted in the
project's <a class="reference external" href="https://github.com/unnecessary-abstraction/meta-linux-mainline/blob/main/ChangeLog.md">ChangeLog</a>.
These include switching the example hardware BSP to Raspberry Pi 4, adding more
QEMU example targets, switching the default LTS kernel series to 5.10, improving
how stable kernels are downloaded and overhauling the scripts used to test and
update this layer.</p>
</div>
<div class="section" id="future-plans">
<h2>Future Plans</h2>
<p>At this point the meta-linux-mainline layer is in a pretty good shape and meets
the use cases which I have. Project maintenance is expected to be fairly
straightforward as updates to the kernel recipes are fully automated. There are
no major changes expected in the near future, the project will just tick over
with minor improvements and regular recipe updates as needed. If you have any
feature requests, please feel free to submit them via the <a class="reference external" href="https://github.com/unnecessary-abstraction/meta-linux-mainline/issues">issue tracker</a>.</p>
<p>At some point I would like to see recipes for RT kernels added to the layer.
This isn't something I immediately need myself, so I'd encourage anyone who has
an immediate need for vanilla RT kernel recipes to contribute this feature to
the project. I'm actually hoping that by the time I next need to play with
realtime features I'll find that the RT patches have been merged fully into
mainline Linux and no separate kernel recipes are actually needed in this layer.</p>
<p>The next Yocto Project release, 3.4 "honister", is expected in October this
year. It's expected that upstream support for the 3.3 "hardknott" release series
will end in November. This layer will be updated around those times to add
support for the "honister" release and remove support for the "hardknott"
release. The current Yocto Project LTS release, 3.1 "dunfell", is expected to be
supported upstream until at least April 2022 and my intention is to continue
supporting the "dunfell" release in this layer until upstream support ends.</p>
</div>