Hi Tim

Many thanks for these instructions, and sorry for the late reply.
However, I wouldn't have forgotten to review it if you had copied the
docs@ mailing list ;-)

On 5/12/22 20:10, Tim Orling wrote:

I have the restructured text conversion far enough along for the
'kernel-lab' to share it now. Because I was last working on this for
Yocto Project Summit 2021.11, the current qemux86 base is on
'honister' (although I am upgrading it to honister-3.4.4 tag).

Please realize there is a lot of history to this material and some of
it was done by folks that have left this mortal coil and some respect
for that posterity is included in this work. We can change and morph
in the future, once it has been captured close to what it is here.

I also have a separate workflow going for the Yocto Project Summit
2022.05 which is in Google Slides and is qemuarm64 based
('kirkstone'). Eventually I will find the time to update the
kernel-lab manual to follow suit, but our collective discussion may
impact that.

You can take a look at YP Summit 2021.11 to see a preview of what is
coming for YP Summit 2022.05 (once I figure out the pesky
printk/pr_info issue):
https://elinux.org/images/b/be/Yps2021.11-handson-kernel.pdf

Current working branch of kernel-lab manual:
https://github.com/moto-timo/yocto-docs/tree/timo/honister/kernel-lab

And the accompanying metadata training materials:
https://github.com/moto-timo/kernel-lab-layers/tree/wip-honister

The intent is that for a given release of the docs, we would have
exercises for  LTS, Stable and Mainline (really this means
current-stable, not -dev). Currently, LTS would be 5.10, Stable would
be 5.15 and Mainline would be 5.17.

The whole instructions look very good and ready for inclusion when the
mentioned repository for the lab layers exists.

I'm starting to run them.

How should we proceed? I'd suggest to:

* Publish the repository for the lab layers at the specified location
* Submit the sources to the docs@ mailing list for public review. I
have a few minor issues to report, and this could happen then.

What do you think?

So far, there's just one thing that bothers me a bit: the .bb or .conf
files that we are supposed to open could be useful to show directly in
the documentation. It looks a bit strange to talk about the contents of
a file without showing it at the same time. I know, there's a risk to
see them getting out of sync with the actual sources.

Maybe we can find a way to include the contents of files from branches
in cloned repositories. This would be handy in many places...

Thanks again,
Cheers
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com