Početak › Forumi › Linuks distribucije › Slackware › Kernel modules
- This topic has 25 odgovora, 7 glasova, and was last updated 19 years, 6 months ranije by
marelli.
-
AutorČlanci
-
10. decembar 2006. u 9:23 am #50458
djux
UčesnikI da si na pocetku instalacije izabrao huge26.s morao bi naknado da instaliras modules ,source i heders posto je 2.4 jos uvek default kernel. Debilno, ali ce se promeniti verovatno u narednoj verziji 🙂
10. decembar 2006. u 12:23 pm #50459slackmaster
UčesnikCisto da dodam na celu ovu pricu: s obzirom da je slack jos uvek po defaultu na 2.4 kernelu, moj je savet svima da se ne “junace” previse, vec da ga instaliraju najpre sa 2.4 kernelom, pa da nakon sto se dokopaju sigurnog tla, isprobavaju 2.6-ticu. To govorim zato sto koristim slack vec par godina i mislim da je jako dobra distribucija, ali nazalost, mnogi ljudi brzo odustanu od njega, jer im se na pocetku dogode neke ovakve nezgode, koje su pre svega rezultat nepotrebnog eksperimentisanja u toku same instalacije. Instalacija slackware-a je veoma jednostavna, takoreci pravolinijska (ako izuzmemo rucno particionisanje na pocetku) a ono sto je jako dobro je sto maksimalno stablino i pouzdano radi sa klasicnom “full” instalacijom, tj. nema potrebe da se smarate sa izborom paketa kao kod nekih drugih “velikih” distro-a, ovde vam sve treba, tako da je izbor krajnje jednostavan. Zato treba odraditi rutinski instalaciju, pa kad se dokopate vase drage konzole, onda cackajte koliko god zelite. Tada jednostavno odete u odgovarajuci direktorijum na install disku i instalirate 2.6 kernel, module, source i nista vise. Header-e NIKAKO NE INSTALIRATI. Headeri se najcesce ne menjaju mnogo od verzije do verzije, i ne sluze mnogo samom kernelu, vec pre svega glibc-u, i pri tom vazi pravilo: sa kojim je headerima kompajliran glibc, ti headeri treba da budu u sistemu! Kod slack-a to su 2.4 header-i, pa tako treba i da ostane.
Nije na odmet da 2.4 ipak ostane kao alernativa, bar za neko vreme dok se ne uverite da vam zaista vise ne treba.
Ja licno uvek sam kompajliram novi kernel, tako da ove prekompajlirane pakete sa install diska nisam koristio. Zato ne znam sta se desava sa /etc/rc.d/rc.modules fajlom prilikom njihove instalacije. Kada rucno kompajlirate kernel 2.6, tada ce na slackware 11-tici biti jos potrebno da kreirate fajl /etc/rc.d/rc.modules-2.6.17, pod pretpostavkom da je to tacna verzija kernela. Ovo nije neophodno jer 11-tica najpre trazi fajl sa verzijom aktivnom kernela, a zatim, ako takvog nema, ipak pokrece /etc/rc.d/rc.modules. Medjutim, moze se desiti da postoje neki moduli koji ce vam biti potrebni na 2.6-tici a opet neki drugi ce vam biti potrebni na 2.4-vorci (npr. kod mene sam na 2.6-tici morao da dodam red /sbin/modprobe psmouse zbog misa, dok sam kod 2.4 morao da odkomentarisem red /sbin/modprobe apm kako bi mi se ATX napajanje samo gasilo). Zato mislim da je dobro sto je Patrick na novom slack-u ostavio mogucnost koriscenja raznih rc.modules-x.xx.xx fajlova,. Dakle ako kompajlirate iz source-a, nakon svega jos iskopirajte /etc/rc.d/rc.modules-2.4.33.3 u novi fajl /etc/rc.d/rc.modules-2.6.17.13 (ili kako se vec zove kernel)
pa onda na toj kopiji vrsite izmene po zelji. Ukoliko ipak odlucite da kernel instalirate iz paketa na disku, mozda se to obavi automatski, nemem pojma 🙂Sve ove kompikacije su rezultat prelaznog perioda (“tranzicije” 🙂 ) u kom se slack trenutno nalazi. Slack je sada napravljen tako da skoro ravnopravno (sa naglaskom na “skoro”) podrzava oba kernela, pa su zato neke stvari komplikovanije nego na starim verzijama Slackware-a. Kada se definitivno predje na 2.6, verovatno ce i Slack malo da prodje kroz “ciscenje”, ali za sada je ovako. Nema veze, bitno je da radi, i to dobro, samo treba malo gimnastike da se sve lepo podesi 🙂
Pozdrav!
10. decembar 2006. u 12:29 pm #50460BrokeBody
Učesnikinstalirate 2.6 kernel, module, source i nista vise. Header-e NIKAKO NE INSTALIRATI. Headeri se najcesce ne menjaju mnogo od verzije do verzije, i ne sluze mnogo samom kernelu, vec pre svega glibc-u, i pri tom vazi pravilo: sa kojim je headerima kompajliran glibc, ti headeri treba da budu u sistemu! Kod slack-a to su 2.4 header-i, pa tako treba i da ostane.
Nije na odmet da 2.4 ipak ostane kao alernativa, bar za neko vreme dok se ne uverite da vam zaista vise ne treba.
Pa da, al’ eto, meni zatrebalo zbog drivera za nVIDIA-u. ???
10. decembar 2006. u 4:34 pm #50461MladenIsakovic
Učesnik[b]slackmaster[/b]
Header-e NIKAKO NE INSTALIRATI. Headeri se najcesce ne menjaju mnogo od verzije do verzije, i ne sluze mnogo samom kernelu, vec pre svega glibc-u, i pri tom vazi pravilo: sa kojim je headerima kompajliran glibc, ti headeri treba da budu u sistemu! Kod slack-a to su 2.4 header-i, pa tako treba i da ostane.Ne kapiram te baš u vezi ovoga; jesi upoređivao sastav kernel headera za 2.4.33 i 2.6.17? Veruj mi da nije isto. Meni trebaju headeri za kernel koji koristim (2.6.17) jer programe koje želim da kompajliram kompajliraću prema 2.6.17 kernelu, a ne prema 2.4.33. Imaš recimo Vector Linux, koji ne dolazi sa kernel source-om, već sa kernel-headerima za dati kernel, i u presudnom broju slučajeva kompajliranje programa i drajvera prođe sa tim, jer su headeri sasvim dovoljni. Glibc jeste iskompajliran za 2.4.33, ali ako nemam kernel-headere za 2.6.17, ja ne mogu da instaliram drajvere za HCF modem, recimo. Logično je da ćeš kompajlirati program da ga koristiš na kernelu koji koristiš, stoga ja smatram da treba imati i kernel-headere za taj kernel.
11. decembar 2006. u 12:00 pm #50462slackmaster
UčesnikNe kapiram te baš u vezi ovoga; jesi upoređivao sastav kernel headera za 2.4.33 i 2.6.17? Veruj mi da nije isto. Meni trebaju headeri za kernel koji koristim (2.6.17) jer programe koje želim da kompajliram kompajliraću prema 2.6.17 kernelu, a ne prema 2.4.33. Imaš recimo Vector Linux, koji ne dolazi sa kernel source-om, već sa kernel-headerima za dati kernel, i u presudnom broju slučajeva kompajliranje programa i drajvera prođe sa tim, jer su headeri sasvim dovoljni. Glibc jeste iskompajliran za 2.4.33, ali ako nemam kernel-headere za 2.6.17, ja ne mogu da instaliram drajvere za HCF modem, recimo. Logično je da ćeš kompajlirati program da ga koristiš na kernelu koji koristiš, stoga ja smatram da treba imati i kernel-headere za taj kernel.
Pa u sustini se slazemo, ali se nismo bas najbolje razumeli. Ono sto sam rekao da header-e ne treba instalirati je prepisano upozorenje koje je sam Patrick ostavio uz odgovarajuci paket na install disku. Prema tome, verovatno da on zna bolje od nas da to ne bi bilo najpametnije raditi.
Sto se tice samih headera, rekao sam da se oni ne razlikuju mnogo od verzije do verzije, ali priznaces da 2.4.33 i 2.6.17 nisu bas “susedne” verzije. Razlike su male izmedju npr 2.6.16 i 2.6.17, ali 2.4 i 2.6 se ipak znatno razlikuju, tako da se i tu slazemo! Jedino se nisam bas najpreciznije izrazio, pa kapiram da je to dovelo do zabune. 🙂
E sad ono glavno: header-i se u sistemu nalaze (bar) na dva mesta:
1) /usr/include/linux (masinski nezavisni headeri) odn. /usr/include/asm (masinski zavisni). Ovi headeri se tu instaliraju prilikom kreiranja distribucije, PRE kompajliranja glibc-a i svega ostalog (to je Pat uradio za nas). Oni ti na neki nacin odredjuju ceo sistem i njih ne treba menjati (to je ono sto sam ja rekao). Velika vecina user space programa nema nikakve interakcije sa kernelom, vec sve radi preko glibc-a, i posredno preko ovih headera, pa su zato oni od sustinske vaznosti za sistem.
2) /usr/src/linux/include/linux (masinski nezavisni) odn. /usr/src/linux/include/asm-i386 (zavisni od arhitekture, ima za svaku arhitekturu po jedan direktorijum). Ovi headeri se instaliraju sa svakim novim source-om koji instaliras, pa tako sve verzije kernela koje imas na sistemu ce imati svoje header-e, koji im potpuno odgovaraju. Tacno je da ne morate imati source kernela da bi vam sistem radio, ali je to uglavnom praksa, pogotovo sto mnogi ljudi vole da kompajliraju iz source-a. Ovi headeri su neophodni za kompajliranje kernel space programa (kao sto su drajveri za modem koje si sam spomenuo; to su u stvari kernel moduli, i ne treba ih mesati sa obicnim user space programima koji obicno nemaju neku preteranu interakciju sa kernelom, bar ne direktnu).Dakle ako ti instaliras header paket sa slack install diska, ti ces prekopirati header-e na prvoj lokaciji (nazovimo ih sistemski headeri) sto generalno nije dobra ideja (ne kazem da ce obavezno da pokvari nesto, mozda i nece, ali cemu nepotreban rizik). Mnogo je pametnije da koristis header-e na drugoj lokaciji koji odgovaraju tvom kernelu (pod uslovom da si instalirao source za 2.6 kernel). Ja kada sam jednom instalirao drajver za intel537 modem, prilikom konfiguracije je konsultovana lokacija /usr/src/linux-`uname -r`/include/linux, tj. ona koja odgovara tekucem kernelu. Ne znam za druge slicne stvari ali verovatno je ili tako ili moze da se podesi da bude tako. Konkretno, ako govorimo o NVIDIA drajverima koje je BrokeBody pominjao, verovatno da postoji neka opcija kojom se lokacija headera postavlja na zeljenu, pa je to po meni neko najbolje resenje. Iskreno, ja nemam pojma nista o NVIDIA niti bilo kojim grafickim drajverima, jer me igrice ne zanimaju niti bilo sta slicno sto zahteva neke fancy drajvere, ovi sto idu uz X su mi sasvim dovoljni, tako da se time nikada nisam bavio. Pretpostavljam da su u pitanju binarni paketi, pa mi bas nije najjasnije sta ce mu uopste header-i ali boze moj, verovatno da mu trebaju, kada ih vec trazi 🙂 Pretpostavljam da se moze konfigurisati tako da konsultuje header-e na specificnoj lokaciji. Dacu samo jos jedan primer da upotpunimo ovu pricu: kada kompajlirate glibc, jedna od opcija je –with-kernel-headers=DIR ili tako nesto, pa verovatno da svaki program koji koristi headere ima neku takvu opciju.
Mislim da su ovo neke dobre smernice kako resavati ovakve probleme. Ako tako nesto ipak ne prodje, evo jos jednog (glupljeg) resenja: privremeno promenite naziv /usr/include/linux direktorijuma u npr. /usr/include/linux-2.4 ; slicno uradite i sa asm direktorijumom. Onda iskopirate headere za 2.6 kernel (prosto sa installpkg, a mozete i sa lokacije /usr/src/linux-2.6.17/include/linux ako ste instalirali source, to je to isto).
Nakon toga radite sta zelite, a ako nesto podje naopako, samo vratite sve kako je bilo i resili ste problem. Ovo je jako glupo resenje, ali eto, mozda nekom i to pomogne u trenutcima ocaja. Ja se sa tim ne bih igrao 🙂Pozdrav!
11. decembar 2006. u 12:14 pm #50463DVSoftware
Učesnik[b]slackmaster[/b]
Header-e NIKAKO NE INSTALIRATI. Headeri se najcesce ne menjaju mnogo od verzije do verzije, i ne sluze mnogo samom kernelu, vec pre svega glibc-u, i pri tom vazi pravilo: sa kojim je headerima kompajliran glibc, ti headeri treba da budu u sistemu! Kod slack-a to su 2.4 header-i, pa tako treba i da ostane.Ja vetju odvalu u svom zhivotu nisam chuo. Ako je ovo Pat rekao, mogu retji samo jedno – Retard… mada iskreno sumnjam da je iz njegovih usta ovo izashlo…
Kernel headeri, kao i headeri bilo koje druge biblioteke sluzhe za to da bi mogao da ih upotrebish iz drugih programa (tj. da ih linkujesh). Drugo, kernel headeri i glibc nemaju ama bash nikakve veze. Glibc ima svoje headere koji su zapravo omogutjavaju korishtjenje standardnih funkcija C programskog jezika. Kernel headeri su ti potrebni kada morash kompajlirati neki driver (tipa nvidia driver, ili driver za modem). Ako se kernel headeri ne slazhu sa trenutno pokrenutim kernelom, netjesh ni motji da kompajlirash bilo shta vezano za kernel… ili ako uspesh da iskompajlirash, netje ti na istom raditi.Savetujem da pre iznoshenja glupih konstatacija prelistate malo internet stranice.
11. decembar 2006. u 12:22 pm #50464DVSoftware
Učesniksada sam primetio da ti zapravo meshash 2 razlichite stvari, a to su
kernel-headers i glibc-kernel-headers11. decembar 2006. u 2:09 pm #50465MladenIsakovic
UčesnikBiće da je to u pitanju.
11. decembar 2006. u 9:45 pm #50466slackmaster
Učesnik[quote][b]slackmaster[/b]
Header-e NIKAKO NE INSTALIRATI. Headeri se najcesce ne menjaju mnogo od verzije do verzije, i ne sluze mnogo samom kernelu, vec pre svega glibc-u, i pri tom vazi pravilo: sa kojim je headerima kompajliran glibc, ti headeri treba da budu u sistemu! Kod slack-a to su 2.4 header-i, pa tako treba i da ostane.Ja vetju odvalu u svom zhivotu nisam chuo. Ako je ovo Pat rekao, mogu retji samo jedno – Retard… mada iskreno sumnjam da je iz njegovih usta ovo izashlo…
Kernel headeri, kao i headeri bilo koje druge biblioteke sluzhe za to da bi mogao da ih upotrebish iz drugih programa (tj. da ih linkujesh). Drugo, kernel headeri i glibc nemaju ama bash nikakve veze. Glibc ima svoje headere koji su zapravo omogutjavaju korishtjenje standardnih funkcija C programskog jezika. Kernel headeri su ti potrebni kada morash kompajlirati neki driver (tipa nvidia driver, ili driver za modem). Ako se kernel headeri ne slazhu sa trenutno pokrenutim kernelom, netjesh ni motji da kompajlirash bilo shta vezano za kernel… ili ako uspesh da iskompajlirash, netje ti na istom raditi.Savetujem da pre iznoshenja glupih konstatacija prelistate malo internet stranice.
[/quote]Ovo je kopija fajla kernel-headers.WARNING sa slackware-ovog instalacionog diska:
CITAT:
This package of 2.6.x based /usr/include/linux and /usr/include/asm headers
is being provided by request for some people who need it in order to compile
ASDL modem drivers for 2.6.x. As a general rule, installing kernel headers
that are newer than the kernel glibc was compiled with *may* cause problems,
so unless you need these for a particular reason it’s best to stick with the
2.4.x kernel-headers package for now.Good luck!
-P.
KRAJ CITATA
Prvo, voleo bih da razgovaramo u prijateljskom tonu, jer na kraju krajeva, svi mi ovde smo na istoj strani. Reci tipa “glupost”, “glupe konstatacije” i sl. ne idu, jer ako procitate sta sve ljudi pisu po forumima na ovom i drugim sajtovima, tema kojom se mi bavimo nije ni malo jednostavna. Kao sto vidite, nisam nista izmislio, i da sam i te kako konsultovao sve sto treba pre nego sto sam napisao sta sam napisao, sto se ne moze reci za sve ucesnike u ovoj diskusiji.
Ako zelite da se malo bolje informisete o ulozi i vaznosti kernel-header-a mozda bi bilo dobro da procitate LFSbook, ili neku slicnu literaturu. Dacu jedan citat iz pomenute knige, koja baca malo svetla na ovu temu:
“For years it has been common practice to use “raw” kernel headers (straight from a kernel tarball) in /usr/include, but over the last few years, the kernel developers have taken a strong stance that this should not be done. This gave birth to the Linux-Libc-Headers Project, which was designed to maintain an API stable version of the Linux headers.”
Ovo potvrdjuje ono sto sam ja obasnjavao u prethodnoj diskusiji, za koju nisam siguran da ste je procitali u celini. Doduse, jos kaze da se danas za glibc koriste nesto “precisceni” kernel header-i, ali ja vam mogu iz prve ruke reci da se slobodno mogu kopirati i “raw” kernel header-i jer sam ja to radio, kada sam pravio svoj distro, po ugledu na LFS. I sve je radilo kako valja. Ako vas ne mrzi, mozete da pogledate fajlove u /usr/include/linux i u /usr/src/linux/include/linux/ i videcete da je uglavnom to – to. Dakle nema zbrke kod mene, ja znam o cemu govorim, mozda je zbrka kod vas.
E sad jos malo edukacije: glibc ima svoje dve strane: stranu ka user space-u i stranu ka kernel space-u. Tacno je da glibc ima svoje header-e koji deklarisu standardne C funkcije (poput stdio.h, stdlib.h itd) i to nije sporno, ali to je API ka user space-u, to jest, to je ono sto aplikativni programi koriste da bi ostvarili neke servise. To sam ja upravo i rekao kada sam pisao da user space programi uglavnom nemaju direktne veze sa kernelom, vec sve to ostvaruju (uglavnom) preko glibc-a i ostalih biblioteka. Medjutim, glibc te zahteve mora na neki nacin da obradi, a jedini nacin da to uradi je da ih, pre ili kasnije, dostavi kernelu. Tako na primer, ako vi pozovete funkciju fopen() iz stdio.h da biste otvorili tok (citaj — fajl) glibc ce otvoriti mnoge bafere i alocirati memoriju za njih, ali ce na kraju ipak morati da pozove sistemski poziv open() (videti man 2 open) koji ce reci kernelu da to uradi za nas. Upravo tome sluze kernel headeri — oni su interfejs glibc-a (i svega ostalog) prema kernelu. To je ono sto kernel moze da uradi, to su servisi koje on nudi. Sve sto se desava na vasem racunaru, pre ili kasnije dodje do kernela, a jedini put do njega je preko API-ja koji nude ovi header-i. Zato su oni neophodni prilikom kompajliranja glibc-a, kako bi ovaj znao sa cim raspolaze i na koji nacin te svoje zahteve moze da isporuci kernelu. Postoje naravno i drugi korisnici kernel header-a, to su najcesce neki dodatni moduli koji rade u kernel space-u, pre svega mislim na razne drajvere za modeme i slicna cuda koja se naknadno dodaju, ali oni su zapravo deo kernela (tj. dodatak na kernel). User space programi uglavnom ne koriste ove header-e, vec se obracaju posredno, preko glibc-a.
Dalje, reci da se heder-i linkuju je krajnje pogresno — linkuju se biblioteke, header-i imaju ulogu samo da deklarisu podatke, konstante i funkcije koje u nekoj biblioteci postoje. Dakle umesto da kucas #include uvek mozes da uradis copy-paste celog sadrzaja tog fajla u tvoj source fajl, jer C kompajler zapravo radi isto. Linkovanje je nesto sto sledi posle, i to sa bibliotekom
(*.so ili *.a fajlovi). Isto tako, reci da kernel headeri i glibc nemaju nikakve veze je potpuno deplasirano, a vidi se iz cele prethodne price: to je glupsot, ali sto bi rekao Sojic, “meni ugladjenost nalaze” da se ne izrazavam na taj nacin, svi smo mi ovde ipak prijatelji.Najzad, ponovo apostrofiram moju izjavu iz prethodne poruke, koju ili niste procitali, ili niste razumeli: kada sam kompajlirao drajver za intel537 modem, prilikom konfiguracije i kasnije kompilacije, korisceni su HEADER-i IZ SOURCE-A tj. sa lokacije /usr/src/linux/include/linux/.
Evo vam malo iz makefile-a:
KERNEL_SOURCE_PATH=/lib/modules/`uname -r`/build/include
INCLUDES = -I $(KERNEL_SOURCE_PATH)/includeDakle, slazemo se da se kernel header-i koriste za kompajliranje ovakvih stvari, ali ovi headeri se nalaze u okviru kernel source-a, a oni se poklapaju sa tvojim kernelom, pa nema problema. Problem je sto ce mozda neki program da ih trazi u /usr/include/linux, gde se nalaze 2.4 header-i i to onda ne odgovara. Ali sam ja upravo to i predlozio: da se pogleda opcija koja menja lokaciju trazenja, npr kao kod glibc-a –with-kernel-headers=/usr/src/linux/include na primer. Ovo bi resio problem. I dalje tvrdim da su header-i u /usr/include/linux/ i u /usr/src/linux-2.4.33.3/include/linux/ isti headeri (uz eventualno neko ciscenje nepotrebih stvari) a vi ako ne verujete, izvolite pa proveravajte.
Stvar je samo u tome sto su header-i u /usr/include/linux ubaceni tu prilikom instalacije glibc-a, dok su ovi drugi deo kernel source-a, ali sustina je ista. Patrick savetuje da se ne istalira paket sa kernel header-ima jer ce on prekopirati 2.6 headere u /usr/include, preko postojecih 2.4 headera, sto moze da napravi probleme. Dakle, ako vam bas trebaju 2.6 header-i, onda je najpametnije da nekako iskoristite header-e iz /usr/src/linux-2.6.17/include/linux/ sto je verovatno moguce, ako se sve lepo podesi. TO SU TI HEADERI — drugih nema!!I na kraju reci da je Patrick “retard” je toliko neumesno da ja stvarno ne znam da li vi za ikoga priznajete da je pametniji od vas, pa cak ni coveka koji vec 13 godina sam odrzava jednu od najpoznatijih Linux distribucija. Svaki dalji komentar je nepotreban.
Ja se nadam da cemo dalju raspravu voditi u prijatnijem tonu, da se ne nadmecemo kao neki klinci u tome ko je pametniji, stvarno ne osecam potrebu da vas ubedjujem da sam bilo sta! Pozdrav!
12. decembar 2006. u 10:57 am #50467BrokeBody
UčesnikA sta je bolje?
Prvo da instaliram Slack sa njegovim default krenelom, pa onda da instaliram 2.6 kernel ili odmah da instaliram sa 2.6 krenelom, pa moduli i ostalo?
-
AutorČlanci
Moraš biti prijavljen da bi postavio komentar u ovoj temi.