slackmaster
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.
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 <nekiheader.h> 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)/include
Dakle, 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!
