[docs][PATCH] kernel-dev: Add FAQ for how to use a vanilla kernel

[docs][PATCH] kernel-dev: Add FAQ for how to use a vanilla kernel

[Joshua Watt]

Adds a FAQ with explicit directions about how to build a vanilla kernel
for a machine.

Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
---
 documentation/kernel-dev/kernel-dev-faq.rst | 49 +++++++++++++++++++++
 1 file changed, 49 insertions(+)

diff --git a/documentation/kernel-dev/kernel-dev-faq.rst b/documentation/kernel-dev/kernel-dev-faq.rst
index 70bf4a2d4..929cc4aad 100644
--- a/documentation/kernel-dev/kernel-dev-faq.rst
+++ b/documentation/kernel-dev/kernel-dev-faq.rst
@@ -79,3 +79,52 @@ following:
 
    APPEND += "printk.time=y initcall_debug debug"
 
+How do I use a vanilla Linux kernel with my machine?
+----------------------------------------------------
+
+The simplest way to use a vanilla kernel is with the ``linux-yocto`` kernel
+maintained by openembedded-core. Using this kernel is as simple as adding the
+following to your machine.conf file:
+::
+
+   # Use a defconfig provided by the kernel. If you are going to provide your
+   # own defconfig in SRC_URI as show below, you'll need to omit this line
+   KBUILD_DEFCONFIG = "multi_v7_defconfig"
+
+   # Use default value for all symbols. This is usually what you want when
+   # providing a defconfig
+   KCONFIG_MODE = "alldefconfig"
+
+   # Make linux-yocto provide the kernel
+   PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+
+   # If you want to use a specific version of the upstream kernel, uncomment
+   # and set this line, otherwise omit it to use the latest stable kernel
+   #PREFERRED_VERSION_linux-yocto = "5.8.%"
+
+You will also need to add a .bbappend in your BSP layer to amend the
+linux-yocto recipe (e.g. recipes-kernel/linux/linux-yocto_%.bbappend):
+::
+
+    FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+    # Uncomment this line to provide your own defconfig file in your BSP layer:
+    # SRC_URI_append_my-machine = " file://defconfig"
+
+    # Marks the recipe as compatible with your machine. Be sure to replace
+    # my-machine with the name of your machine
+    COMPATIBLE_MACHINE .= "|my-machine"
+
+You can also apply patches and config fragements in the bbappend if desired,
+see :ref:`kernel-dev/kernel-dev-common:applying patches` and
+:ref:`kernel-dev/kernel-dev-common:changing the configuration` in the Kernel
+dev manual. It is recommended that you use ``_append_my-machine`` to prevent
+these changes from inadverently leaking into other machine configurations
+
+.. note::
+    You will notice that this is will still pull the kernel source from `the
+    Yocto Kernel git repo
+    <https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/>`_, however it is
+    using the default value for :term:`KBRANCH` (e.g. ``"v5.8/standard/base"``)
+    which is an exact mirror of the upstream kernel.
+
-- 
2.28.0

Re: [docs][PATCH] kernel-dev: Add FAQ for how to use a vanilla kernel

[Joshua Watt]

On Tue, Oct 20, 2020 at 12:03 PM Joshua Watt <jpewhacker@gmail.com> wrote:
>
> Adds a FAQ with explicit directions about how to build a vanilla kernel
> for a machine.
>
> Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
> ---
>  documentation/kernel-dev/kernel-dev-faq.rst | 49 +++++++++++++++++++++
>  1 file changed, 49 insertions(+)
>
> diff --git a/documentation/kernel-dev/kernel-dev-faq.rst b/documentation/kernel-dev/kernel-dev-faq.rst
> index 70bf4a2d4..929cc4aad 100644
> --- a/documentation/kernel-dev/kernel-dev-faq.rst
> +++ b/documentation/kernel-dev/kernel-dev-faq.rst
> @@ -79,3 +79,52 @@ following:
>
>     APPEND += "printk.time=y initcall_debug debug"
>
> +How do I use a vanilla Linux kernel with my machine?
> +----------------------------------------------------
> +
> +The simplest way to use a vanilla kernel is with the ``linux-yocto`` kernel
> +maintained by openembedded-core. Using this kernel is as simple as adding the
> +following to your machine.conf file:
> +::
> +
> +   # Use a defconfig provided by the kernel. If you are going to provide your
> +   # own defconfig in SRC_URI as show below, you'll need to omit this line
> +   KBUILD_DEFCONFIG = "multi_v7_defconfig"
> +
> +   # Use default value for all symbols. This is usually what you want when
> +   # providing a defconfig
> +   KCONFIG_MODE = "alldefconfig"
> +
> +   # Make linux-yocto provide the kernel
> +   PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
> +
> +   # If you want to use a specific version of the upstream kernel, uncomment
> +   # and set this line, otherwise omit it to use the latest stable kernel
> +   #PREFERRED_VERSION_linux-yocto = "5.8.%"
> +
> +You will also need to add a .bbappend in your BSP layer to amend the
> +linux-yocto recipe (e.g. recipes-kernel/linux/linux-yocto_%.bbappend):
> +::
> +
> +    FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> +
> +    # Uncomment this line to provide your own defconfig file in your BSP layer:
> +    # SRC_URI_append_my-machine = " file://defconfig"
> +
> +    # Marks the recipe as compatible with your machine. Be sure to replace
> +    # my-machine with the name of your machine
> +    COMPATIBLE_MACHINE .= "|my-machine"
> +
> +You can also apply patches and config fragements in the bbappend if desired,
> +see :ref:`kernel-dev/kernel-dev-common:applying patches` and
> +:ref:`kernel-dev/kernel-dev-common:changing the configuration` in the Kernel
> +dev manual. It is recommended that you use ``_append_my-machine`` to prevent
> +these changes from inadverently leaking into other machine configurations
> +
> +.. note::
> +    You will notice that this is will still pull the kernel source from `the
> +    Yocto Kernel git repo
> +    <https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/>`_, however it is
> +    using the default value for :term:`KBRANCH` (e.g. ``"v5.8/standard/base"``)
> +    which is an exact mirror of the upstream kernel.

This is a lie. I thought it was the upstream mirror, but it's not.
v5.8/base is the mirror and this one has a few extra patches.

> +
> --
> 2.28.0
>

Re: [docs][PATCH] kernel-dev: Add FAQ for how to use a vanilla kernel

[Quentin Schulz]

Hi Joshua,



On October 20, 2020 7:03:26 PM GMT+02:00, Joshua Watt <JPEWhacker@gmail.com> wrote:
>Adds a FAQ with explicit directions about how to build a vanilla kernel
>for a machine.
>
>Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
>---
> documentation/kernel-dev/kernel-dev-faq.rst | 49 +++++++++++++++++++++
> 1 file changed, 49 insertions(+)
>
>diff --git a/documentation/kernel-dev/kernel-dev-faq.rst
>b/documentation/kernel-dev/kernel-dev-faq.rst
>index 70bf4a2d4..929cc4aad 100644
>--- a/documentation/kernel-dev/kernel-dev-faq.rst
>+++ b/documentation/kernel-dev/kernel-dev-faq.rst
>@@ -79,3 +79,52 @@ following:
> 
>    APPEND += "printk.time=y initcall_debug debug"
> 
>+How do I use a vanilla Linux kernel with my machine?
>+----------------------------------------------------
>+
>+The simplest way to use a vanilla kernel is with the ``linux-yocto``
>kernel
>+maintained by openembedded-core. Using this kernel is as simple as
>adding the
>+following to your machine.conf file:
>+::
>+
>+   # Use a defconfig provided by the kernel. If you are going to
>provide your
>+   # own defconfig in SRC_URI as show below, you'll need to omit this

s/show/shown/

>line
>+   KBUILD_DEFCONFIG = "multi_v7_defconfig"
>+
>+   # Use default value for all symbols. This is usually what you want
>when
>+   # providing a defconfig
>+   KCONFIG_MODE = "alldefconfig"
>+

KCONFIG_MODE is not explained in the Variables Glossary, could you please fix that?

>+   # Make linux-yocto provide the kernel
>+   PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
>+
>+   # If you want to use a specific version of the upstream kernel,
>uncomment
>+   # and set this line, otherwise omit it to use the latest stable
>kernel

Here's to hoping that no layer with a higher priority provide their own linux-yocto :)

>+   #PREFERRED_VERSION_linux-yocto = "5.8.%"
>+
>+You will also need to add a .bbappend in your BSP layer to amend the
>+linux-yocto recipe (e.g. recipes-kernel/linux/linux-yocto_%.bbappend):

``linux-yocto`` and the path in double tick too.

>+::
>+
>+    FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>+
>+    # Uncomment this line to provide your own defconfig file in your
>BSP layer:
>+    # SRC_URI_append_my-machine = " file://defconfig"
>+
>+    # Marks the recipe as compatible with your machine. Be sure to
>replace
>+    # my-machine with the name of your machine
>+    COMPATIBLE_MACHINE .= "|my-machine"
>+

I don't think spaces matter in COMPATIBLE_MACHINE but happy to be proven otherwise. In that case, probably += would be better as it's usually what's used throughout the docs? As to not confuse beginners?

>+You can also apply patches and config fragements in the bbappend if
s/fragements/fragments/
>desired,
>+see :ref:`kernel-dev/kernel-dev-common:applying patches` and
>+:ref:`kernel-dev/kernel-dev-common:changing the configuration` in the
>Kernel
>+dev manual. It is recommended that you use ``_append_my-machine`` to
>prevent
>+these changes from inadverently leaking into other machine
>configurations

Missing dot at the end of the sentence.

>+
>+.. note::
>+    You will notice that this is will still pull the kernel source

Not a native, but my doubts on "you will notice" being correct?

s/is//

>from `the
>+    Yocto Kernel git repo
>+    <https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/>`_,

:yocto_git:`the Yocto Kernel git repo </cgit/cgit.cgi/linux-yocto/>`

Thanks,
Quentin
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [docs][PATCH] kernel-dev: Add FAQ for how to use a vanilla kernel

[Robert Berger]

Hi,

On 20/10/2020 21:14, Joshua Watt wrote:
> On Tue, Oct 20, 2020 at 12:03 PM Joshua Watt <jpewhacker@gmail.com> wrote:
>> +.. note::
>> +    You will notice that this is will still pull the kernel source from `the
>> +    Yocto Kernel git repo
>> +    <https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/>`_, however it is
>> +    using the default value for :term:`KBRANCH` (e.g. ``"v5.8/standard/base"``)
>> +    which is an exact mirror of the upstream kernel.
> 
> This is a lie. I thought it was the upstream mirror, but it's not.
> v5.8/base is the mirror and this one has a few extra patches.
> 

And exactly because only Bruce knows (most of the time) what is in all 
those funny branches why not use upstream (kernel.org) for a vanilla kernel?

Regards,

Robert

Re: [docs][PATCH] kernel-dev: Add FAQ for how to use a vanilla kernel

[Bruce Ashfield]

On Tue, Oct 20, 2020 at 5:05 PM Robert Berger@yocto.user
<robert.berger.yocto.user@gmail.com> wrote:
>
> Hi,
>
> On 20/10/2020 21:14, Joshua Watt wrote:
> > On Tue, Oct 20, 2020 at 12:03 PM Joshua Watt <jpewhacker@gmail.com> wrote:
> >> +.. note::
> >> +    You will notice that this is will still pull the kernel source from `the
> >> +    Yocto Kernel git repo
> >> +    <https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/>`_, however it is
> >> +    using the default value for :term:`KBRANCH` (e.g. ``"v5.8/standard/base"``)
> >> +    which is an exact mirror of the upstream kernel.
> >
> > This is a lie. I thought it was the upstream mirror, but it's not.
> > v5.8/base is the mirror and this one has a few extra patches.
> >
>
> And exactly because only Bruce knows (most of the time) what is in all
> those funny branches why not use upstream (kernel.org) for a vanilla kernel?
>

We are documented how the single linux-yocto repository can be used to
track tip (master), or any of the -stable upstream kernels
(<version>/base), or the yocto specifics (<version>/standard/base),
without needing to create 'x' recipes to do it. It is just a branch
switch away.

Someone can always use upstream in their own kernel recipe, we are
just using this doc to describe what's in oe-core itself.

Bruce

> Regards,
>
> Robert



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: [docs][PATCH] kernel-dev: Add FAQ for how to use a vanilla kernel

[Joshua Watt]

On Tue, Oct 20, 2020 at 4:14 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>
> On Tue, Oct 20, 2020 at 5:05 PM Robert Berger@yocto.user
> <robert.berger.yocto.user@gmail.com> wrote:
> >
> > Hi,
> >
> > On 20/10/2020 21:14, Joshua Watt wrote:
> > > On Tue, Oct 20, 2020 at 12:03 PM Joshua Watt <jpewhacker@gmail.com> wrote:
> > >> +.. note::
> > >> +    You will notice that this is will still pull the kernel source from `the
> > >> +    Yocto Kernel git repo
> > >> +    <https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/>`_, however it is
> > >> +    using the default value for :term:`KBRANCH` (e.g. ``"v5.8/standard/base"``)
> > >> +    which is an exact mirror of the upstream kernel.
> > >
> > > This is a lie. I thought it was the upstream mirror, but it's not.
> > > v5.8/base is the mirror and this one has a few extra patches.
> > >
> >
> > And exactly because only Bruce knows (most of the time) what is in all
> > those funny branches why not use upstream (kernel.org) for a vanilla kernel?
> >
>
> We are documented how the single linux-yocto repository can be used to
> track tip (master), or any of the -stable upstream kernels
> (<version>/base), or the yocto specifics (<version>/standard/base),
> without needing to create 'x' recipes to do it. It is just a branch
> switch away.
>
> Someone can always use upstream in their own kernel recipe, we are
> just using this doc to describe what's in oe-core itself.

There is a lot at play here; IMHO, using the branches Bruce maintains
is actually the best option (if you can use it) because those branches
are tested; I assume he's not making changes and diverging from
upstream for the fun of it; the changes fix actual bugs. For example,
I converted meta-rockchip to use the standard/base branches, and
really haven't had to worry about it since; I have pretty high
confidence those are going to continue to just work. meta-rockchip
gets to freeload off of Bruce's hard work to upgrade the kernel and
stays relatively up-to-date without much effort on my part :)

OOTH, I get that people really just want to use the vanilla kernel
(even though they probably *also* want the changes Bruce made), and it
certainly "feels" like a better story if we can do that. As Bruce
pointed out, you can do that by setting KBRANCH to the <version>/base
branch. I think the part that's missing there is that you also have to
set SRCREV to a SHA1 on the branch, probably with some strange
override? Maybe `SRCREV_machine_pn-linux-yocto = "..."` ? And, if you
do that, I think the other problem is that `LINUX_VERSION` will then
be wrong, so you might need to override that also. This also means
that you don't get the latest versions "automatically" since you have
to manually bump the SRCREV. In general it seems really easy for the
linux-yocto recipes to get out of sync with your settings and cause
confusion. We could maybe figure out a way to have a SRCREV for the
upstream branch in the linux-yocto recipes, but it's weird and
problematic to have a SRCREV pointing to something that's not tested
(back the the point of why we have the "standard" branches in the
first place, they are tested and work).

>
> Bruce
>
> > Regards,
> >
> > Robert
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II

Re: [docs][PATCH] kernel-dev: Add FAQ for how to use a vanilla kernel

[akuster]

On 10/20/20 11:14 AM, Joshua Watt wrote:
> On Tue, Oct 20, 2020 at 12:03 PM Joshua Watt <jpewhacker@gmail.com> wrote:
>> Adds a FAQ with explicit directions about how to build a vanilla kernel
>> for a machine.
>>
>> Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
>> ---
>>  documentation/kernel-dev/kernel-dev-faq.rst | 49 +++++++++++++++++++++
>>  1 file changed, 49 insertions(+)
>>
>> diff --git a/documentation/kernel-dev/kernel-dev-faq.rst b/documentation/kernel-dev/kernel-dev-faq.rst
>> index 70bf4a2d4..929cc4aad 100644
>> --- a/documentation/kernel-dev/kernel-dev-faq.rst
>> +++ b/documentation/kernel-dev/kernel-dev-faq.rst
>> @@ -79,3 +79,52 @@ following:
>>
>>     APPEND += "printk.time=y initcall_debug debug"
>>
>> +How do I use a vanilla Linux kernel with my machine?
>> +----------------------------------------------------
>> +
>> +The simplest way to use a vanilla kernel is with the ``linux-yocto`` kernel
>> +maintained by openembedded-core. Using this kernel is as simple as adding the
>> +following to your machine.conf file:
>> +::
>> +
>> +   # Use a defconfig provided by the kernel. If you are going to provide your
>> +   # own defconfig in SRC_URI as show below, you'll need to omit this line
>> +   KBUILD_DEFCONFIG = "multi_v7_defconfig"
>> +
>> +   # Use default value for all symbols. This is usually what you want when
>> +   # providing a defconfig
>> +   KCONFIG_MODE = "alldefconfig"
>> +
>> +   # Make linux-yocto provide the kernel
>> +   PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
>> +
>> +   # If you want to use a specific version of the upstream kernel, uncomment
>> +   # and set this line, otherwise omit it to use the latest stable kernel
>> +   #PREFERRED_VERSION_linux-yocto = "5.8.%"
>> +
>> +You will also need to add a .bbappend in your BSP layer to amend the
>> +linux-yocto recipe (e.g. recipes-kernel/linux/linux-yocto_%.bbappend):
>> +::
>> +
>> +    FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>> +
>> +    # Uncomment this line to provide your own defconfig file in your BSP layer:
>> +    # SRC_URI_append_my-machine = " file://defconfig"
>> +
>> +    # Marks the recipe as compatible with your machine. Be sure to replace
>> +    # my-machine with the name of your machine
>> +    COMPATIBLE_MACHINE .= "|my-machine"
>> +
>> +You can also apply patches and config fragements in the bbappend if desired,
>> +see :ref:`kernel-dev/kernel-dev-common:applying patches` and
>> +:ref:`kernel-dev/kernel-dev-common:changing the configuration` in the Kernel
>> +dev manual. It is recommended that you use ``_append_my-machine`` to prevent
>> +these changes from inadverently leaking into other machine configurations
>> +
>> +.. note::
>> +    You will notice that this is will still pull the kernel source from `the
>> +    Yocto Kernel git repo
>> +    <https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/>`_, however it is
>> +    using the default value for :term:`KBRANCH` (e.g. ``"v5.8/standard/base"``)
>> +    which is an exact mirror of the upstream kernel.
> This is a lie.
No. You listen to this old man ; )

was I close?

-Armin
>  I thought it was the upstream mirror, but it's not.
> v5.8/base is the mirror and this one has a few extra patches.
>
>> +
>> --
>> 2.28.0
>>
>>
>> 
>>

Re: [docs][PATCH] kernel-dev: Add FAQ for how to use a vanilla kernel

[akuster]

On 10/20/20 2:14 PM, Bruce Ashfield wrote:
> On Tue, Oct 20, 2020 at 5:05 PM Robert Berger@yocto.user
> <robert.berger.yocto.user@gmail.com> wrote:
>> Hi,
>>
>> On 20/10/2020 21:14, Joshua Watt wrote:
>>> On Tue, Oct 20, 2020 at 12:03 PM Joshua Watt <jpewhacker@gmail.com> wrote:
>>>> +.. note::
>>>> +    You will notice that this is will still pull the kernel source from `the
>>>> +    Yocto Kernel git repo
>>>> +    <https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/>`_, however it is
>>>> +    using the default value for :term:`KBRANCH` (e.g. ``"v5.8/standard/base"``)
>>>> +    which is an exact mirror of the upstream kernel.
>>> This is a lie. I thought it was the upstream mirror, but it's not.
>>> v5.8/base is the mirror and this one has a few extra patches.
>>>
>> And exactly because only Bruce knows (most of the time) what is in all
>> those funny branches why not use upstream (kernel.org) for a vanilla kernel?
>>
> We are documented how the single linux-yocto repository can be used to
> track tip (master), or any of the -stable upstream kernels
> (<version>/base), or the yocto specifics (<version>/standard/base),
> without needing to create 'x' recipes to do it. It is just a branch
> switch away.
>
> Someone can always use upstream in their own kernel recipe, we are
> just using this doc to describe what's in oe-core itself.

this is what I just did for the meta-odroid.

https://gitlab.com/akuster/meta-odroid/-/blob/master/recipes-kernel/linux/linux-yocto_5.8.bbappend

It  you don't have your own kernel fragments, it could be simpler.

-armin

>
> Bruce
>
>> Robert
>
>
>
> 
>