| rev |
line source |
|
Hans-G?nter@1217
|
1 SliTaz Linux Kernel Readme
|
|
Hans-G?nter@1217
|
2 ==========================
|
|
Hans-G?nter@1217
|
3
|
|
Hans-G?nter@1217
|
4 1. Updating the Kernel version
|
|
Hans-G?nter@1217
|
5 ------------------------------
|
|
Hans-G?nter@1217
|
6
|
|
Hans-G?nter@1217
|
7 There's a tiny tool called `up-linux.sh`: just update $VERSION in the main
|
|
Hans-G?nter@1217
|
8 "linux" receipt and then run this script. Versions in the all the related
|
|
Hans-G?nter@1217
|
9 packages will be updated. We can do it easy because we have defined variables
|
|
Hans-G?nter@1217
|
10 in the "linux" package receipt:
|
|
Hans-G?nter@1217
|
11
|
|
Hans-G?nter@1217
|
12 * SPLIT: list of packages that use files compiled with the "linux" package;
|
|
Hans-G?nter@1217
|
13 * SIBLINGS: list of packages that builds using the same sources, but with
|
|
Hans-G?nter@1217
|
14 the different purpose (to build man pages, API headers, config tool, etc).
|
|
Hans-G?nter@1217
|
15
|
|
Hans-G?nter@1217
|
16
|
|
Hans-G?nter@1217
|
17 2. Updating the Kernel config
|
|
Hans-G?nter@1217
|
18 -----------------------------
|
|
Hans-G?nter@1217
|
19
|
|
Hans-G?nter@1217
|
20 You can use your old `.config` to build newer Kernels: it'll forgive you some
|
|
Hans-G?nter@1217
|
21 inconsistency in the configuration doing it's best. Note, using old `.config`
|
|
Hans-G?nter@1217
|
22 you'll lack the new possibilities provided by the new Kernel, while some older
|
|
Hans-G?nter@1217
|
23 options may no longer be used.
|
|
Hans-G?nter@1217
|
24
|
|
Hans-G?nter@1217
|
25 To update the configuration options you may use your old `.config` as the base
|
|
Hans-G?nter@1217
|
26 (see `stuff/linux-slitaz.config`) with the tool provided in the "slitaz-dev"
|
|
Hans-G?nter@1217
|
27 package (please, read it's description).
|
|
Hans-G?nter@1217
|
28
|
|
Hans-G?nter@1217
|
29 Some useful links provided by Thomas Hinterberger (a.k.a. Kult-ex) where you
|
|
Hans-G?nter@1217
|
30 can get examples of configs used in the different Linus distributions:
|
|
Hans-G?nter@1217
|
31
|
|
Hans-G?nter@1217
|
32 * Opensuse: https://github.com/openSUSE/kernel-source/blob/master/config/i386/default
|
|
Hans-G?nter@1217
|
33 * Fedora: http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/refs/
|
|
Hans-G?nter@1217
|
34 * Alpine: https://github.com/alpinelinux/aports/blob/master/main/linux-vanilla/config-vanilla.x86
|
|
Hans-G?nter@1217
|
35 * Manjaro: https://github.com/manjaro/packages-core/blob/master/linux49/config
|
|
Hans-G?nter@1217
|
36
|
|
Hans-G?nter@1217
|
37 It is strongly NOT recommended to just edit `.config` as text file (unless you
|
|
Hans-G?nter@1217
|
38 know all the consequences):
|
|
Hans-G?nter@1217
|
39
|
|
Hans-G?nter@1217
|
40 Automatically generated file; DO NOT EDIT.
|
|
Hans-G?nter@1217
|
41
|
|
Hans-G?nter@1217
|
42 You may make mistakes. Geven module can't be builtin (=y) if it depends on the
|
|
Hans-G?nter@1217
|
43 loadable module (=m). Switching some options on (=y) and off (# ... is not set)
|
|
Hans-G?nter@1217
|
44 will add or remove a bunch of other options. Switching some option on may
|
|
Hans-G?nter@1217
|
45 automatically switch some other option on, as described in the Kconfig* files:
|
|
Hans-G?nter@1217
|
46
|
|
Hans-G?nter@1217
|
47 * selecting CONFIG_BLOCK will auto-select CONFIG_SBITMAP too
|
|
Hans-G?nter@1217
|
48 (see $src/block/Kconfig);
|
|
Hans-G?nter@1217
|
49 * CONFIG_SND_HDA_I915 depends on CONFIG_DRM_I915 and CONFIG_SND_HDA_CORE
|
|
Hans-G?nter@1217
|
50 (see $src/sound/hda/Kconfig).
|
|
Hans-G?nter@1217
|
51
|
|
Hans-G?nter@1217
|
52 It's (near to) impossible to track all that dependencies in mind.
|
|
Hans-G?nter@1217
|
53
|
|
Hans-G?nter@1217
|
54 How do you know it's time to reconfigure your Kernel? Check cooking log for the
|
|
Hans-G?nter@1217
|
55 "(NEW)" items. The greater their number the stronger you need to reconfigure it.
|
|
Hans-G?nter@1217
|
56
|
|
Hans-G?nter@1217
|
57
|
|
Hans-G?nter@1217
|
58 3. Splitting the Kernel modules
|
|
Hans-G?nter@1217
|
59 -------------------------------
|
|
Hans-G?nter@1217
|
60
|
|
Hans-G?nter@1217
|
61 Yet another big task is to split Kernel modules into different "linux-*"
|
|
Hans-G?nter@1217
|
62 packages. We need to keep the main "linux" package light, splitting rarely used
|
|
Hans-G?nter@1217
|
63 options into another packages.
|
|
Hans-G?nter@1217
|
64
|
|
Hans-G?nter@1217
|
65 We need to keep balance between number of "linux-*" packages and the number of
|
|
Hans-G?nter@1217
|
66 the modules inside them. Package with the only one module, as well as package
|
|
Hans-G?nter@1217
|
67 with the thousands of modules are not a good solution. User will not need the
|
|
Hans-G?nter@1217
|
68 most of the modules in the package thanks to the great variety of sound cards,
|
|
Hans-G?nter@1217
|
69 network cards and other hardware that performs a similar function, but which
|
|
Hans-G?nter@1217
|
70 can not be present simultaneously in one configuration of the user equipment.
|
|
Hans-G?nter@1217
|
71
|
|
Hans-G?nter@1217
|
72 Since Linux Kernel 4.9 we use special rules to find and split the modules into
|
|
Hans-G?nter@1217
|
73 the different "linux-*" packages, as well as to find modules that should be
|
|
Hans-G?nter@1217
|
74 inside the base "linux" package (please, see $stuff/split.rules). Rules format
|
|
Hans-G?nter@1217
|
75 is simple: one rule on line; each rule composed from two parts separating
|
|
Hans-G?nter@1217
|
76 spaces:
|
|
Hans-G?nter@1217
|
77
|
|
Hans-G?nter@1217
|
78 * ruleset name: we use "acpi" for "linux-acpi" package, "crypto" for
|
|
Hans-G?nter@1217
|
79 "linux-crypto" package, etc. We use just "linux" for the base "linux"
|
|
Hans-G?nter@1217
|
80 package. Note, we may use the same rules for the "linux64-*" and
|
|
Hans-G?nter@1217
|
81 "linux-libre-*" packages as well as for "linux-*" packages.
|
|
Hans-G?nter@1217
|
82 * rule itself: it's just the job for the `find` command making you free to
|
|
Hans-G?nter@1217
|
83 add/remove modules more frequently than changing the rules itself. It save
|
|
Hans-G?nter@1217
|
84 you from listing all the thousands of modules here. Three different examples
|
|
Hans-G?nter@1217
|
85 of the rules itself showing their simplicity, strength and flexibility:
|
|
Hans-G?nter@1217
|
86
|
|
Hans-G?nter@1217
|
87 * `drivers/net/tun.ko.xz`: find and copy given module;
|
|
Hans-G?nter@1217
|
88 * `net/bluetooth`: find and copy all the modules inside the given directory
|
|
Hans-G?nter@1217
|
89 as well as from all including sub-directories;
|
|
Hans-G?nter@1217
|
90 * `net/ipv4/*.ko.xz`: the same as above but only in the given directory,
|
|
Hans-G?nter@1217
|
91 skipping all including sub-directories.
|
|
Hans-G?nter@1217
|
92
|
|
Hans-G?nter@1217
|
93 Processing rules also automatically finds all the module dependencies to copy
|
|
Hans-G?nter@1217
|
94 all them too. So there's impossible situation with the missing dependencies.
|
|
Hans-G?nter@1217
|
95
|
|
Hans-G?nter@1217
|
96 The goal is to copy each module to one or another package. Sometimes you need
|
|
Hans-G?nter@1217
|
97 to tweak existing rules or add new one. Please, make the rule as easier as you
|
|
Hans-G?nter@1217
|
98 can. If possible, avoid the particular module names, using directories names
|
|
Hans-G?nter@1217
|
99 instead. You'll see in the end of the cooking log if there's unpackaged modules.
|
|
Hans-G?nter@1217
|
100
|
|
Hans-G?nter@1217
|
101 Also, there's little tool called `check-split.sh`. It produces a big bold table
|
|
Hans-G?nter@1217
|
102 containing all the modules with the information of packages where they lives now
|
|
Hans-G?nter@1217
|
103 and description provided with the certain module. You can run this script after
|
|
Hans-G?nter@1217
|
104 the splitting is over (after the "linux" package is done).
|
|
Hans-G?nter@1217
|
105
|
|
Hans-G?nter@1217
|
106 You can open the table on the wide screen in the text editor, or convert it to
|
|
Hans-G?nter@1217
|
107 html using command `sundown modules.split > modules.split.html` and open it in
|
|
Hans-G?nter@1217
|
108 the web browser.
|
|
Hans-G?nter@1217
|
109
|
|
Hans-G?nter@1217
|
110 Analizing the table will help you split the modules. If the certain module
|
|
Hans-G?nter@1217
|
111 belongs to two, three or more packages, it tells us that we need to put this
|
|
Hans-G?nter@1217
|
112 module to the base "linux" package: each "linux-*" package depends on the
|
|
Hans-G?nter@1217
|
113 "linux" package. But note, the single module may attract the bunch of other
|
|
Hans-G?nter@1217
|
114 modules as dependencies to the "linux" package, while this behavior may be
|
|
Hans-G?nter@1217
|
115 undesirable. Note, in some cases you may make the module builtin (=y).
|
|
Hans-G?nter@1217
|
116
|
|
Hans-G?nter@1217
|
117 If the number of the packages belongs to two packages (for example to bigger
|
|
Hans-G?nter@1217
|
118 "linux-media" and to smaller "linux-radio") and we can easily differentiate
|
|
Hans-G?nter@1217
|
119 them, consider to use $DEPENDS on one of the receipt (the bigger one): package
|
|
Hans-G?nter@1217
|
120 "linux-media" is depends on "linux-radio" and all that common modules belongs
|
|
Hans-G?nter@1217
|
121 only to "linux-radio" package.
|
|
Hans-G?nter@1217
|
122
|
|
Hans-G?nter@1217
|
123 Packages receipts are mostly generic, while all the splitting job is done by
|
|
Hans-G?nter@1217
|
124 script `$stuff/tools/copy_modules.sh` using the `$stuff/split.rules`.
|
|
Hans-G?nter@1217
|
125
|
|
Hans-G?nter@1217
|
126 Steps to make split perfect:
|
|
Hans-G?nter@1217
|
127
|
|
Hans-G?nter@1217
|
128 1. Cook "linux" with all "linux-*" packages being cooking automatically too.
|
|
Hans-G?nter@1217
|
129 2. Run `check-split.sh` and analize the modules table. Finish if you are
|
|
Hans-G?nter@1217
|
130 satisfied with the result.
|
|
Hans-G?nter@1217
|
131 3. Change `split.rules`.
|
|
Hans-G?nter@1217
|
132 4. Run the command `cook linux --pack` to re-pack the "linux" and "linux-*"
|
|
Hans-G?nter@1217
|
133 package using new rules.
|
|
Hans-G?nter@1217
|
134 5. Examine the packing log: http://slitaz/cooker/cooker.cgi?log=linux-pack.log
|
|
Hans-G?nter@1217
|
135 6. Proceed to step 2.
|