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