Administrace komentářů

Tady bych doporučil zkusit zkompilovat jenom moduly a prostě nahradit ath9k za ten hacknutý. Pokud bude konfigurace kernelu a build systém v rozumné shodě s tím, co tam už běží, mělo by to být v pohodě a nový ath9k poslouží jako drop-in replacement toho původního. Kompilovat celý kernel asi nemá smysl. Já třeba sice mám na svých počítačích vlastnoručně nakonfigurované a zkompilované kernely, ale kdyby se mě někdo zeptal na seznam výhod, asi bych fakt hodně váhal.

Co je potřeba pro build kernelu, o tom se aspoň ve zkratce zmiňuje stránka toho distra. To je ovšem hodně ve zkratce. Možná by se ale dal aplikovat nějaký návod pro CentOS, RedHat nebo Fedoru, jak se tak dívám. To by bylo potřeba zkusit.

Rád tady samozřejmě popíšu, jak bych kernel vybuildil já. Zdaleka ne všechny kroky jsou nezbytné pro tento případ, takže si z toho můžeš vybrat a poupravit jen to, co opravdu potřebuješ. Můžeš použít buď zdrojáky z distribuce, nebo aktuální kernelový strom. To první zaručí kompatibilitu modulů s aktuálně běžícím kernelem, zatímco to druhé zaručí kompatibilitu mého patche se zdrojáky, tedy přinejmenším u verze 4.1.6. Pokud se patch nepodaří aplikovat (což je u starších kernelů docela pravděpodobné), v tomto konkrétním případě se svět neposere, protože není až tak těžké příslušné řádky v souborech dohledat a aplikovat patch manuálně. Jen je to úsilí navíc. Každopádně těch pár relevantních řádků vypadá stejně už tak od kernelu 3.5, takže by měly být celkem v pohodě k nalezení, i pokud patch řekne, že neví a nezná.

Naklonování celé Git repository stačí udělat jen jednou v životě. Pak už se bude vždy pouze (celkem rychle a efektivně, s ohledem na její velikost) aktualizovat:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git ~/src/linux

Kompletní build celého kernelu bych udělal asi takto:

# Pár nastaení, která je potřeba upravit podle distribuce.
VERSION='4.1.6'
LINUX_SOURCE_PATH="${HOME}/src/linux"
KERNEL_IMAGE='/boot/vmlinuz-linux'

set -e
cd "$LINUX_SOURCE_PATH"
# Tady zruším všechny změny, všechny pozůstatky po buildech atd.
git clean -f -d
git checkout .
git checkout master
# Aktualizace repository, aby byly k dispozici nejnovější verze.
git pull
# Checkout zvolené verze do pracovních souborů.
git checkout "v$VERSION"
# Aplikace zázračného patche. Jo, přesně tady to je.
patch -lp1 <<-ATH9K_HACK
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 5e15e8e..083f731 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2383,7 +2383,7 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah)
        u8 ant_div_ctl1, tx_chainmask, rx_chainmask;
  
        eeval = ah->eep_ops->get_eeprom(ah, EEP_REG_0);
-       regulatory->current_rd = eeval;
+       regulatory->current_rd = 32971;
  
        if (ah->opmode != NL80211_IFTYPE_AP &&
            ah->hw_version.subvendorid == AR_SUBVENDOR_ID_NEW_A) {
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 0e347f8..11b0a52 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -2576,7 +2576,7 @@ static void restore_regulatory_settings(bool reset_user)
                        restore_custom_reg_settings(&rdev->wiphy);
        }
  
-       regulatory_hint_core(world_alpha2);
+       regulatory_hint_core("CZ");
  
        /*
         * This restores the ieee80211_regdom module parameter
@@ -3145,7 +3145,7 @@ int __init regulatory_init(void)
        user_alpha2[1] = '7';
  
        /* We always try to get an update for the static regdomain */
-       err = regulatory_hint_core(cfg80211_world_regdom->alpha2);
+       err = regulatory_hint_core("CZ");
        if (err) {
                if (err == -ENOMEM)
                        return err;
ATH9K_HACK
# Získání konfiguračního souboru existujícího kernelu.
# Buď je v /proc/config.gz, nebo taky ne.
if [[ -f /proc/config.gz ]]; then
	zcat /proc/config.gz > ./.config
else
	if ! scripts/extract-ikconfig "$KERNEL_IMAGE" > ./.config; then
		cp "/boot/config-${VERSION}" ./.config
		# A jinak konec, tady už prostě vaříme z vody.
	fi
fi
# Proč ne native, když už to stejně celé kompilujeme.
export KCFLAGS='-march=native -O2 -pipe'
export KAFLAGS='-march=native -O2 -pipe'
# Spuštění buildu ve screenu; oldconfig a menuconfig s trochou interakce.
# modules je v podstatě to jediné, co je potřeba spustit v případě modulů.
screen -d -m sh -c \
	'for i in oldconfig menuconfig clean prepare bzImage modules;
		do make -j 8 $i;
	 done'
# S následujícím opatrně, ať to ještě vůbec někdy nabootuje.
sudo make -j modules_install

Z výše uvedeného bude asi nejlepší zvolit kompilaci pouze modulů (cíl modules) a pak najít, kde je ath9k (find -type f -name ath9k.ko) a přepsat jím manuálně ten původní v /lib/modules/…/<verze_kernelu>. Pokud po přebootování (nebo případně po modprobe -r ath9k && modprobe ath9k) bude vše v pořádku, tj. v dmesg se objeví blablabla CZ a bude možné zvolit nějaké kanály pro access point (tj. hostapd bude provozuschopný a nebude nadávat), poté se dá uvažovat o tom, jak takovou změnu uložit nějak nastálo. Variant je několik:

1. Vlastní build distribučního kernelu (pokud jsou všechny moduly zabalené přímo s ním).
2. Vlastní build balíčku s Atherosem (pokud je ath9k v nějakém odděleném balíčku).
3. Jednoduchý skript, který prostě hrubou silou zkompiluje a nahradí ath9k, kdykoliv to bude potřeba, a na kterém bude záviset třeba hostapd. (Například vhodný systemd unit file spouštějící nějaký build skript. Tedy podle toho, co daná distribuce používá.)
4. Nějaké sofistikovanější automatizované řešení pomocí akmod, jestli distribuce něco takového má. akmod například na Fedoře automaticky kompiluje a aktualizuje moduly od grafických karet NVidia a další podobné těžko balíčkovatelné kusy kernelu.

Tohle už ale záleží na tom, co konkrétně distribuce dělá a umí, jaký systém pro build balíčků používá a tak dále. Abych to shrnul, doporučil bych napřed nějakým rychlým manuálním hackem vyzkoušet, jestli to celé vůbec má smysl, tj. jestli upravený modul bude fungovat, jak má. Teprve pokud se ukáže, že je to v pohodě, stojí za to investovat čas a úsilí do nějakých trvalejších úprav, které budou v lepším souladu s danou distribucí.

„Instalace“ samotného kernelu (například pokud by se zkompilovaná verze modulů lišila od verze distribučního kernelu a šlo by fakt jen o to nabootovat aspoň jednou alternativní kernel a zkusit, co to dělá) se dá provést zhruba nějak takto:

# Po editaci /boot/grub*/grub*.cfg a přidání kopie nějaké funkční položky:
cp /var/inst/linux/System.map /boot/System.map-alternative
cp /var/inst/linux/arch/x86_64/boot/bzImage /boot/vmlinuz-linux-alternative
# Následující je pouze pro ArchLinux; Fedora má dracut, ostatní kdovíco.
mkinitcpio -g /boot/vmlinuz-linux-alternative.img -c /etc/mkinitcpio.conf -k "$VERSION"-dirty
# Přípona -dirty se po některých patchích u verzí objeví, jindy ne.
# Poslední řádka výstupu z make modules_install ukáže, jak to je.

Pozor ovšem na ten initrd / initramfs / initcpio / kdovíjaktomuříkají, protože bez vygenerování správného obrazu pro daný kernel to většinou nenabootuje. Zažil jsem ty krásné časy, kdy initramfs nebyl povinný, takže stačilo zakompilovat přímo do kernelu jeden filesystémový driver, aby kernel dokázal otevřít hlavní filesystém s ostatními kernelovými moduly a initem, a bylo vys(ta)ráno. Leč časy se mění.

Možná se vyplatí vsadit na jistotu a zkusit spíš vybuildit kernelový balíček přímo build systémem dané distribuce. Tam je aspoň menší riziko, že člověk na něco podstatného zapomene. I tak doufám, že tahle odpověď aspoň něco ozřejmí — třeba to, kde se vyrábějí kernelové moduly.