add test rst file

This commit is contained in:
2021-05-19 15:33:53 +02:00
parent 032e76ff94
commit 7a3ac6c797

83
TEST.rst Normal file
View File

@@ -0,0 +1,83 @@
Some thoughts on Eudyptula
==========================
Working with linux-next
-----------------------
Normally, we should follow Linuxs branch, and add **linux-next**
remote, as explained in `kernel.org
help <https://www.kernel.org/doc/man-pages/linux-next.html>`__.
However, to build my own kernel for real usage, a stable one is much
better, which tags are not in Linuss branch.
Adding Gregs stable branch remote branch would just be a pain in the
ass.
However, I had this discussion on IRC:
::
2021/05/13 11:40 <bodiccea> I am currently using Linus's branch, with another remote (linux-next).
For the first time, I would like to use "for real" the latest stable
(as of today: 5.12.3), but I cannot find such tag. I just added "stable"
remote (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git),
and currently it is being updated. Is it the correct way to have both
linux-next and a useable/stable kernel ?
2021/05/13 12:12 <gregkh> bodiccea: yes.
2021/05/13 12:12 <gregkh> bodiccea: you can just use that linux.git tree as I keep it up to date
with Linus's tree every -rc release at the longest, and sometimes daily
if I'm bored :)
2021/05/13 12:13 * gregkh is reminded to go update it right now...
So, the better is to completely forget about Linus branch. The
procedure is therefore:
1. **Clone gregkhs stable blanch :**
``$ git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Cloning into 'linux'... ...``
2. **Add a linux-next remote tracking branch :**
``$ cd linux $ git remote add linux-next https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git``
3. **Fetch linux-next and tags :**
``$ git fetch linux-next $ git fetch --tags linux-next``
4. **Regular tracking :**
``$ git checkout master # to be safe ... $ git remote update``
Get latest versions
-------------------
1. **Latest stable versions**
``$ git tag -l "v*" | grep -ve -rc | sort -V | tail -5 v5.11.22 v5.12 v5.12.1 v5.12.2 v5.12.3``
2. **Latest -rc versions**
``$ git tag -l "v*" | grep -e -rc | sort -V | tail -5 v5.12-rc6 v5.12-rc7 v5.12-rc8 v5.13-rc1 v5.13-rc2``
3. **Latest linux-next versions**
``$ git tag -l "next-*" | tail -5 next-20210512 next-20210513 next-20210514 next-20210518 next-20210519``
Kernel config (Ubuntu)
----------------------
We should keep a .config somewhere, that we can use as a starting point
for new kernels. Here: ../
Doc: `issue with AD9467 <https://lkml.org/lkml/2021/3/18/1007>`__ (Fixed
as of 5.12.5) `issue with signed
kernel <https://askubuntu.com/questions/1329538/compiling-the-kernel-5-11-11>`__
1. **First time, get latest Ubuntu kernel config file** \``\` $ cd linux
$ git checkout TAG $ cp /boot/config-x.y.z-t-generic .config $ make
olddefconfig
# disable trusted keys $ scripts/config set-str SYSTEM_TRUSTED_KEYS
"" or: scripts/config disable SYSTEM_TRUSTED_KEYS
$ cp .config ../kernel-config/$(git describe tags) … \``\`
2. **Then, just update config for new versions**
``$ cd linux $ git checkout TAG $ cp ../kernel-config/TAG .config $ make olddefconfig or: make oldconfig ...``
Kernel build (deb package)
--------------------------
::
$ cd linux
$ make -j 2 bindeb-pkg LOCALVERSION=-bodi