mkimage-profiles/features.in/kernel/config.mk

# choose std kernel flavour for max RAM size support
ifeq (i586,$(ARCH))
BIGRAM := std-pae
else
BIGRAM := std-def
endif

use/kernel:
	@$(call add_feature)
ifeq (,$(filter-out e2k%,$(ARCH)))
	@$(call try,KFLAVOURS,elbrus-def)
else
ifeq (,$(filter-out aarch64 armh,$(ARCH)))
	@$(call try,KFLAVOURS,mp)
else
ifeq (,$(filter-out riscv64,$(ARCH)))
	@$(call try,KFLAVOURS,un-def)
else
	@$(call try,KFLAVOURS,std-def)
endif
endif
endif

# r8168 is a kludge, never install it by default
use/kernel/net:
	@$(call add,THE_KMODULES,e1000e igb)
	@$(call add,MAIN_KMODULES,r8168 rtl8168)

use/kernel/wireless: use/firmware/wireless
	@$(call add,THE_KMODULES,bcmwl ndiswrapper)

use/kernel/laptop: use/firmware/laptop
	@$(call add,THE_KMODULES,omnibook tp_smapi)

use/kernel/desktop:
	@$(call add,THE_KMODULES,lirc v4l)

use/kernel/server:
	@$(call add,THE_KMODULES,ipset kvm)
kernel: factor the former lib/kernel.mk in It wasn't spotted when introducing the distinct kernel feature; will need fixup as we meet packaged ARM/PPC kernels. 2013-01-25 00:55:56 +04:00			`# choose std kernel flavour for max RAM size support`
			`ifeq (i586,$(ARCH))`
			`BIGRAM := std-pae`
			`else`
			`BIGRAM := std-def`
			`endif`

initial kernel and metadata features This further refines the modular build by making metadata being a clearly separated feature rather than having to rely on runtime tests, and also by moving the code which cares for kernel bits of base installation (.base list) in a feature of its own. There's more to it but let's get the ball rolling first. 2012-05-08 18:59:57 +04:00			`use/kernel:`
			`@$(call add_feature)`
kernel: use different default flavour for e2k This might evolve into some form of per-arch logic, or otherwise x86 might get moved into a feature of its own instead of being the presumed one. The first step is done. 2019-04-26 20:25:34 +03:00			`ifeq (,$(filter-out e2k%,$(ARCH)))`
			`@$(call try,KFLAVOURS,elbrus-def)`
kernel: use different default flavour for aarch64, armh 2019-04-29 19:47:04 +03:00			`else`
			`ifeq (,$(filter-out aarch64 armh,$(ARCH)))`
			`@$(call try,KFLAVOURS,mp)`
kernel: use different default flavour for riscv64 2019-05-13 13:21:21 +03:00			`else`
			`ifeq (,$(filter-out riscv64,$(ARCH)))`
			`@$(call try,KFLAVOURS,un-def)`
kernel: use different default flavour for e2k This might evolve into some form of per-arch logic, or otherwise x86 might get moved into a feature of its own instead of being the presumed one. The first step is done. 2019-04-26 20:25:34 +03:00			`else`
kernel: try std-def instead of forcing it KFLAVOURS could have been set earlier and got overridden here. 2017-08-02 15:51:18 +03:00			`@$(call try,KFLAVOURS,std-def)`
kernel: use different default flavour for e2k This might evolve into some form of per-arch logic, or otherwise x86 might get moved into a feature of its own instead of being the presumed one. The first step is done. 2019-04-26 20:25:34 +03:00			`endif`
kernel: use different default flavour for aarch64, armh 2019-04-29 19:47:04 +03:00			`endif`
kernel: use different default flavour for riscv64 2019-05-13 13:21:21 +03:00			`endif`
kernel: introduced use/kernel/net target The various 8168 and friends among kernel modules have finally been pushed into a designated target so that RM doesn't have to care which particular additional ethernet modules are available in this particular branch and kernel. Tweak distros as appropriate. NB: maybe* this is required by distro/.base either. 2013-02-21 13:49:32 +04:00
kernel, stage1: don't provide r8168.ko by default It conflicts with r8169.ko inobviously. The whole mess looks like this: - r8169.ko doesn't work for all of Realtek 8111/8168/8169 mutations - r8168.ko works with some of the chips r8169.ko doesn't - r8168.ko also works with many chips r8169.ko works with - r8169.ko is provided by kernel-image package (thus default) - r8168.ko is provided by kernel-modules-r8168 package (optional) - kernel-modules-r8168 package requires r8168-blacklist package - r8168-blacklist package is a one-liner that blacklists r8169.ko - STAGE1_KMODULES wouldn't include r8168 (std-def) or rtl8168 (led-ws) - sub.in/stage1/modules would mention r8168.ko (m-p-d: r8169.ko) So a LiveCD built with use/kernel/net might work with RTL8111/8110 just fine when booted live but fail to automatically load the module when installed onto hard drive; manual modprobe r8169 would work though. NB: some of the chips (those available to me) would work just fine both ways -- this has contributed to fixing this that late. Bottom line: do not install backup/kludge drivers overriding main ones by default! Thanks sem@ for providing the crucial hint. 2014-03-13 22:16:48 +04:00			`# r8168 is a kludge, never install it by default`
kernel: introduced use/kernel/net target The various 8168 and friends among kernel modules have finally been pushed into a designated target so that RM doesn't have to care which particular additional ethernet modules are available in this particular branch and kernel. Tweak distros as appropriate. NB: maybe* this is required by distro/.base either. 2013-02-21 13:49:32 +04:00			`use/kernel/net:`
kernel, stage1: don't provide r8168.ko by default It conflicts with r8169.ko inobviously. The whole mess looks like this: - r8169.ko doesn't work for all of Realtek 8111/8168/8169 mutations - r8168.ko works with some of the chips r8169.ko doesn't - r8168.ko also works with many chips r8169.ko works with - r8169.ko is provided by kernel-image package (thus default) - r8168.ko is provided by kernel-modules-r8168 package (optional) - kernel-modules-r8168 package requires r8168-blacklist package - r8168-blacklist package is a one-liner that blacklists r8169.ko - STAGE1_KMODULES wouldn't include r8168 (std-def) or rtl8168 (led-ws) - sub.in/stage1/modules would mention r8168.ko (m-p-d: r8169.ko) So a LiveCD built with use/kernel/net might work with RTL8111/8110 just fine when booted live but fail to automatically load the module when installed onto hard drive; manual modprobe r8169 would work though. NB: some of the chips (those available to me) would work just fine both ways -- this has contributed to fixing this that late. Bottom line: do not install backup/kludge drivers overriding main ones by default! Thanks sem@ for providing the crucial hint. 2014-03-13 22:16:48 +04:00			`@$(call add,THE_KMODULES,e1000e igb)`
			`@$(call add,MAIN_KMODULES,r8168 rtl8168)`
firmware: factored out kmodules to kernel Maybe firmware feature should be merged into kernel feature as the firmware binaries added by it are only used by kernel but let's clean up a bit at a time. 2014-08-29 15:36:05 +04:00
firmware, kernel, wireless: fixup interdeps It's unreasonable for firmware to depend on kernel, the features should go in the other way around. 2016-03-23 11:58:44 +03:00			`use/kernel/wireless: use/firmware/wireless`
firmware: factored out kmodules to kernel Maybe firmware feature should be merged into kernel feature as the firmware binaries added by it are only used by kernel but let's clean up a bit at a time. 2014-08-29 15:36:05 +04:00			`@$(call add,THE_KMODULES,bcmwl ndiswrapper)`
kernel: add desktop, laptop targets This has been borrowed from m-p-d for Centaurus, actually. 2016-03-23 12:04:13 +03:00
			`use/kernel/laptop: use/firmware/laptop`
kernel, firmware: fix KMODULES use Looks like a thinko by now... 2018-08-10 14:11:35 +03:00			`@$(call add,THE_KMODULES,omnibook tp_smapi)`
kernel: add desktop, laptop targets This has been borrowed from m-p-d for Centaurus, actually. 2016-03-23 12:04:13 +03:00
			`use/kernel/desktop:`
kernel, firmware: fix KMODULES use Looks like a thinko by now... 2018-08-10 14:11:35 +03:00			`@$(call add,THE_KMODULES,lirc v4l)`
kernel, regular.mk: use/kernel/server It's apparently needed for ALT Server and has been used implicitly for server-pve starterkit. 2018-08-10 14:15:42 +03:00
			`use/kernel/server:`
			`@$(call add,THE_KMODULES,ipset kvm)`