Dotaz: Ovladače - jak to funguje doopravdy?

[Jagged]

Prosím ostřílené linuxáky, aby tohle nebrali jako pokus o trolling, ale jako dotaz člověka co teprve objevuje základy unixových systémů.

Jak je to v Linuxu s ovladači zařízení? Jako člověk dříve používající Windows jsem byl zvyklý, že ke každému složitějšímu zařízení bylo potřeba nainstalovat ovladač, aby to uspokojivě fungovalo. V Linuxu (Kubuntu) všechno co mám funguje "hned", i třeba mobil nebo ExpressCard eSata co si ve Win bez ovladačů z CD ani neškrtla. Trochu jsem hledal a pochopil jsem to správně, že linuxové jádro si přímo v sobě nese ovladače ke všemu možnému i nemožnomu hardwaru? Není takový systém zbytečně molochoidní? Není třeba možné, aby si instalátor při instalaci "osahal" hardware a zbytečné ovladače zrušil, nebo dal nabídku jestli nechci něco konkrétního vyhodit?

Odpovědi

[Michal Kubeček]

Drivery zařízení jsou až na výjimky překládány jako moduly a do paměti se natahují jen ty, které jsou opravdu potřeba. Teoreticky je možné nepotřebné moduly ani neinstalovat na disk, ale to už má dnes smysl spíš jen na speciálních zařízeních, kde je velikost filesystému minimální, ne na normálním počítači.

[Jakub Lucký]

Za dodatek stojí, že některá zařízení potřebují třeba ještě firmware, který se z licenčních důvodů distribuuje úplně zvlášť, nebo jen v non-free repozitářích

[R]

Doplnim, ze vsetky moduly spolu na disku maju typicky do 100 MB.

[gogol]

Ovladace zariadeni na Linuxe vychadzaju z pribuznych typov hardware. Kazdy hardware a jeho nasledna vylepsenie (modifikacia) ma vela spolocnych charakteristik, tudiz je zbytocne ku kazdemu pisat zvlast ovladac. Jeden ovladac pokryje celu typovu radu. Lisi sa to len v detailoch.

Navyse je Linux vyrazne modularny, takze napriklad pre wifi karty je cela vrstva MLME (MAC Layer Managament Entity) pritomna v systeme len raz pre akykolvek wifi adapter.

[ali]

Tak i já se zeptám.. mam notebook Fujitsu Amilo Li 3910 s grafikou Intel a je to silene chciply.. pomale vykreslovani, nizke rozliseni... proste hruza.. vsude ctu, ze po instalaci Ubuntu jedou ovladace Intel bez problemu a neni potreba vubec nic delat.. vzdyt se to neda skoro pouzivat prosim poradte co s tim.. Ubuntu 64bit 14.04

[Jendа]

Podíval bych se, jaký ovladač to používá. Najdeš to ve /var/log/Xorg.0.log. Měl by to být driver intel.

[ali]

no jo, je tam Intel.. ted jsem jeste spustil tohle: http://www.omgubuntu.co.uk/2014/07/intel-graphics-stack-2014-q2-update a po instalaci a restartu zadna zmena

[ali]

JEDNODUŠE vyřešeny všechny problémy s Intel grafikou:

http://ubuntuforums.org/archive/index.php/t-2148909.html

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_osi=" Tahle blbost mi zabila cely vecer:)

[Heron]

Trochu jsem hledal a pochopil jsem to správně, že linuxové jádro si přímo v sobě nese ovladače ke všemu možnému i nemožnomu hardwaru?

V zásadě ano.

Není takový systém zbytečně molochoidní?

Není. Jak psali správně předřečníci, tak v jádře nemusí být zkompilováno vše a typicky ani není.

Není třeba možné, aby si instalátor při instalaci "osahal" hardware a zbytečné ovladače zrušil, nebo dal nabídku jestli nechci něco konkrétního vyhodit?

Detekce HW se ve skutečnosti provádí při každém bootu. Není tedy problém vzít HDD, strčit ho do kompletně jiného HW (samozřejmně se zachováním platformy, nelze vzít OS pro ARM a strčit ho na x86) a prostě nabootovat. Až na případné drobnosti (např: pokud je konfigurace sítě spojená s MAC adresou síťovky, tak je potřeba to nastavit znovu pro nový HW) OS bez problémů najede. Tohle na Widlích jen tak neuděláte.

To co chcete, tedy osahat si hw a zbytek vyhodit samozřejmně můžete. Nástroje které vám s tím pomohou existují. Spousta lidí si kompiluje jádro přesně na míru jejich požadavkům a hw (s tím rizikem, že nepůjde tak snadno přepojit disk do jiného kompu) a mají to skutečně minimální. Ale tohle není nic pro začátečníka.

Opravdu tohle není nutné ani žádoucí dělat. Za normální situace je stejně načteno pouze to, co je nutné a ten zbytek na disku příliš nezabírá (pár desítek MB).

[rastos]

To co chcete, tedy osahat si hw a zbytek vyhodit samozřejmně můžete. Nástroje které vám s tím pomohou existují.

Mohol by si o tých nástrojoch byť konkrétnejší?

[Heron]

Tak pomocí config.gz (/proc/config.gz nebo některá distra to ukládájí společně s jádrem do /boot) se dá vytáhnout aktuální konfigurace (distribučního) jádra a od té se odpíchnout. (Ta je funkční.) Pomocí lsmod lze zjistit, které moduly se aktuálně používají. Ty je možné zkompilovat přímo do jádra. Ostatní moduly potom z jádra vyházet (pomocí klasického menuconfig) a vyzkoušet. Je to na hodně dlouhé zimní večery.

Balíčkář jádra z nějakého distra, pokud tady je, tak poradí víc.

[Michal Kubeček]

Ty je možné zkompilovat přímo do jádra. Ostatní moduly potom z jádra vyházet (pomocí klasického menuconfig) a vyzkoušet.

Ještě chybí podstatná informace: k čemu by to vlastně mělo být dobré. Třeba pro někoho, kdo je vývojář a potřebuje za den otestovat spoustu buildů s různými verzemi opravy (která bohužel zrovna není v modulu), to smysl mít může. Nebo na nějakém tom embedded zařízení s malou CF kartou coby kořenovým filesystémem. Ale na normálním systému?

Je to na hodně dlouhé zimní večery.

No právě. Je spousta zábavnějších způsobů, jak je strávit. Je spousta užitečnějších způsobů, jak je strávit. A je i docela dost způsobů, které jsou zároveň zábavnější i užitečnější.

Balíčkář jádra z nějakého distra, pokud tady je, tak poradí víc.

Ten spíš bude řešit pravý opak. Ne jak udělat jádro na míru jednomu konkrétnímu systému, ale jak udělat balíček s jádrem tak, aby rozumně fungoval na co nejširším spektru systémů.

[Heron]

Ještě chybí podstatná informace: k čemu by to vlastně mělo být dobré.

Tak původní tazatel se ptá na molochovitost a rastos se ptá na nástroje, které pomůžo se té molochovitosti zbavit. Myslím, že pokud původní tazatel zjistí, že se ušetří max. 40MB, tak si třeba přestane myslet, že je to moloch (nebo alespoň bude mít srovnání s jinými OS). A vůbec u všech tohle přispěje k větší znalosti věcí týkajících se modulů v linuxu. Jinými slovy, místo na disku se tím neušetří, ale alespoň už bude jasné proč.

Je spousta zábavnějších způsobů, jak je strávit. Je spousta užitečnějších způsobů, jak je strávit. A je i docela dost způsobů, které jsou zároveň zábavnější i užitečnější.

Tak tohle je na osobních preferencích. Někoho může bavit z jádra modul po modulu odstraňovat nepotřebné prvky. Nevidím na tom nic divného (v konstrastu s některými jinými druhu zábavy).

Ten spíš bude řešit pravý opak.

Jasně, ale asi bude mít lepší představu o nástrojích, které by se na to dali použít. Distribuční baliči jader musí nějak zjistit, jaká je nejvhodnější množina nastavení distribučního jádra a proč.

[rastos]

Ještě chybí podstatná informace: k čemu by to vlastně mělo být dobré.

Tak původní tazatel se ptá na molochovitost a rastos se ptá na nástroje, které pomůžo se té molochovitosti zbavit.

Orientovať sa podľa toho, ktoré moduly dokáže loadnúť jadro v ktorom je "všetko" rieši možno otázku ovládačov pre niektoré zariadenia, ale je to biedne riešenie. Skúsim načrtnúť niektoré oblasti (netvrdím, že všetky sú podobne reálne):

• vybrať len iptables targety, ktoré sa skutočne používajú
• voľby, ktoré sa nedajú kompilovať ako moduly (CONFIG_PATA_*, CONFIG_POWER_AVS, CONFIG_SND_HDA_CODEC_*, CONFIG_EFI_PARTITION, CONFIG_ACPI_* )
• Machine Check/microcode pre Intel/AMD
• ECC memory support
• USB EHCI/OHCI/AHCI
• MMC/SD support
• RTC support
• CD/DVD filesystem support
• Hardware crypto devices
• ...

[nobody]

takze uz znas nastroj, je to tvuj mozek kterej ma zkusenosti s kernel a tree deps :)

[R]

Minimalizacia konfiguracie sa hodi pri hladani bugu bisekciou, ked treba skompilovat a otestovat priblizne 15 verzii. Na vykonnom HW sa to potom skompiluje za jednotky minut a vysledok (jadro+moduly) je mozne rychlo preniest na HW, kde prebieha testovanie.

[nobody]

nebo si do toho oklesteneho kernelu kompilujes jen 15 verzi v modulu a mas to za par vterin, pokud to neni zrovna pripad kdy jako modul ti to zkompilovat nejde (principem nebo problemem) :)

[R]

Ked je medzi funkcnym a nefunkcnym kernelom 5 verzii, tak musim skompilovat vsetko. Resp. make si sam urci, co bude kompilovat - a ku konci bisekcie uz kompiluje menej.

[Sten]

Můžete třeba použít seznam z lsmod a všechny ostatní moduly z /lib/modules/VERZE_JÁDRA smazat. Tohle vypíše seznam aktuálně nepoužívaných modulů:

find /lib/modules/$(uname -r) -name '*.ko' | grep -v "$(lsmod | awk '{print $1"\\.ko$"}' | tr _ -)"

Pokud nakonec přihodíte tohle, zjistíte i to, kolik (jak málo) místa byste ušetřil:

| xargs du -b | awk '{s+=$1} END{print s}' | numfmt --to=iec-i --suffix=B

Ale pokud ty moduly opravdu odstraníte, tak riskujete, že následně připojené zařízení (myš, mobil, foťák, flash disk, tiskárna, …) nebude fungovat, protože nebude mít ovladače.

[nobody]

to je celkem prasarna :) ale kdyz uz tak pripadne usb zarizeni to chce vsechny spolecne pripojit pred tim promazanim, primountovat vsechny disky (i flashky) ktere maji jiny filesystem nez systemovej disk... a mit radeji pripravene livecd nebo liveusb :)

# a zalohu puvodnich nepromazanejch
sudo cp -a /lib/modules/$(uname -r) /lib/modules/$(uname -r).bak

# regenerovat modulum zavislosti,aliasy,symboly :)
sudo depmod

# odebrat pripadne nepouzivane a tedy odmazavane moduly pro initramfs
vi /etc/initramfs-tools/modules

# a regenerovat initramfs
update-initramfs -k $(uname -r) -u

hlavne ale tazatele je potreba spis nasmerovat na to, ze tim nic neziska :) to uz spis at si zkompiluje vlastni jadro, tim se aspon neco nauci :)

[jadd]

to uz spis at si zkompiluje vlastni jadro, tim se aspon neco nauci :)

Ve skutečnosti v podstatě nic, pokud nebude k tomu číst dokumentaci, jediné co se naučí, jaký všemožný hw v tom jádru je, a co mu po jeho zásahu nebude fungovat po kompilaci, pokud bude sahat na to o čem si přečetl kulový a o čem neví podrobnosti které i v dokumentaci chybí. Když se zkompiluje jakýkoliv modul do jádra viděný v lsmod, nemusí pak fungovat, s výchozím nastavením, protože mu nejdou předat všechny parametry např. ALSA. Takže souhlas kompilování jádra je dobrá zábava, pokud chci zabít čas, ale naprosto zbytečná!

[jadd]

Ty podrobnosti jsou hlavně probírány na lwn.com

[nobody]

ve skutecnosti si zprovozni prostredi v kterem pujde kompilovat jadro, muze si projit strukturu ovladacu jadra pomoci menu, nauci se kompilovat, a a a proste je blbost tvrdit ze se nic nenauci, nemusi se z neho stat kernel guru, nemusi mit vysledek super kompaktrni minimalisticke optimalizovane jadro, staci ze se s tim seznami a ziska urcite zkusenosti, takze se dozvi neco co nevedel, treba z nej bude casem kernel vyvojar jen diky tomu, nebo si jen proste nekdy zkompiluje neco ze zdrojaku protoze se nebude bat pustit configure&&make, nebo si jen uvedomi ze ma moznosti ktere na uzavrenem systemu nexistuji, ale neni to zadna nutnost, jen moznost volby :)

[Heron]

+1

[jadd]

lwn.net Takhle, jediné co je opravdu užitečné změnit pro desktop je optimalizace latence a procesoru. Ale pokud distribuce má obraz jádra právě optimalizovaný pro desktop jako OpenSUSE pak to opravdu postrádá smysl. Navíc není pak snadné optimalizovat i initramfs ve který je stejně moduly naplněn a bez něho nebude fungovat stejně splash (oberázek při startu). Všude se najde jak zkompilovat jádro ale o initramfs (kompletně) nic, takže pak bude optimalizováno ale při startu naběhne jen černá konzole s výpisy.

[nobody]

pockej, pockej... :) ja neobhajuju nutnost optimalizace kernelu, uz sem tu psal ze je vhodne vysvetlit ze je mu to v podstate na nic a ze nejde u jadra mluvit o nejake molochovosti :) obhajoval sem to ze pri vlastni kompilaci kernelu ma moznost se tim neco naucit, to neco co potrebuje k tomu aby na vlastnim pc zkompiloval vlastni kernel :)

[jadd]

Já taky doplňoval jen sebe (initramdisk - initrd), podívej se pořádně na strukturu vlákna

[mhepp]

Já bych přidal takový postřeh z praxe...

V práci máme docela dost různých PC v centrální správě. Kompletní množina OVLADAČŮ pro win pro tuto množinu HW má cca 14GB. Ovladači nemyslím takové ty různé aplikace na houby přiložené ke všemu, ale skutečně jen sys a inf soubory. A na každém jednotlivém počítači naběhne Linux, který podporuje řekl bych že vše a komprimovaný systém má cca 90MB (jádro, moduly a rootfs).

Doplním, že HW jsou běžné pracovní stanice (~4000ks, cca 200 různých HW), k málokteré (jednotky až nižší desítky) je připojeno něco víc než klávesnice, myš, monitor a ethernet (a USB flashdisk později). Linux chystá automatickou instalaci Windows a bootuje kompletně ze sítě, takže potřebuje podporu pro v podstatě celý systém.

Takže chápu podezřívavost Windowsákům k pouhým 160MB ovladačů. Jak to kua může všechno fungovat??

[Radek Hladik]

Ještě bych dodal, že situace bohužel není úplně tak růžová, i když to často není vina Linuxu.

U levnějšího HW je často tendence přesouvat práci zařízení do jeho ovladače, typickým příkladem jsou různé GDI tiskárny, kde driver obsahuje téměř všechno, co bylo možno přesunout z vlastní tiskárny do SW. Dalším příkladem jsou různé pseudoraid řadiče, kde se o vlastní fungování raidu stará kód v driveru místo čipu na kartě (nemusím snad dodávat, že takové raidy nepoužívat, nepoužívat nebo alespoň případně nepoužívat ).

Dalším problémem je, že někteří výrobci nechtějí zveřejňovat kódy od svých ovladačů, takže se pak do jádra nedostanou. Řeší se to často buď pomocí binárního firmware nebo jako nvdia, že v jádře je jakýsi "bridge", který používá binární megablob...

A poslední poznámka je ohledně závislosti na verzi jádra. Pokud je modul součástí kernelu, tak je pevně svázán s danou verzí a leckdy není možnost ho vyhodit a použít modul z jiného jádra. Takže pokud například jádro 3.tuším asi 15 mělo chybu v intel_idle driveru, tak můžete modul pouze zakázat a nepoužít, případně si přeložit jádro bez něj, ale ne už vzít modul z 3.14... Tedy jde to, ale není to nic pro začátečníka. A pokud naopak máte driver, který se dokompilovává (t.j. není součástí distribuce kernelu), tak ho musíte při každé změně kernelu překládat znovu.

Ale obvykle vetšina HW funguje bez problému okamžitě ("sama od sebe"), popsané věci se týkají buď ne tak populárních zařízení nebo jsou další drivery v distirbuci zahrnuté od jejího výrobce, často v nějakém non-free repositáři nebo tak podobně...

A k tomu překládání vlastního jádra a promazávání modulů... Opravdu to za to nestojí - je to hodně práce, která vyžaduje dobrou znalost HW, různých HW API a fungování v jádře, je to náchylné k fatální chybě a nezískáte tím nic - pár 10-100MB na disku, a teoreticky o trochu vyšší výkon, ale to je většinou tak minimální rozdíl, a to ještě buhví jestli, že to za to ani nestojí... Běžný uživatel to často dělá pouze v případě, že potřebuje rozfungovat nějaký HW, který mu nefunguje, ale i tam někdy bývá jednodušší prostě koupit jiný HW, který je lépe podporován...

[Michal Kubeček]

A pokud naopak máte driver, který se dokompilovává (t.j. není součástí distribuce kernelu), tak ho musíte při každé změně kernelu překládat znovu.

Při každé ne. Přinejmenším v některých distribucích se v rámci updatů zachovává kABI, takže out-of-tree moduly překompilovávat není potřeba.

[R]

Doplnim, ze drivery pre tlaciarne a skenery nie su sucastou jadra.