Zelf Kernel Modules Maken

[anoniem]

Hallo, Na e.e.a. te hebben gelezen zou ik graag wat willen experimenteren met eigen geschreven kernel modules. Ik heb nog nooit een eigen kernel gemaakt of zelfstandig kernelmodules geladen etc., maar dat lijkt me een overkoombaar probleem. Waar ik meer voor vrees is dat ik door domme / slechte code misschien mijn systeem verkloot. Is dit een reëel risico ? Zo ja...hoe kan ik dit voorkomen ? Zelf zat ik te denken om een extra kernel te maken speciaal om mee te experimenteren. Als er dan iets fout gaat, dan kan ik hopelijk gewoon restarten met de huidige kernel en evt. schade herstellen ? Is dit mogelijk en afdoende ? O kan ik beter een testsysteempje ritselen ? P&B

[anoniem]

Je kunt prima meerdere kernels naast elkaar gebruiken. Het ergste wat kan gebeuren met een nieuwe kernel is dat je systeem niet meer boot (Kernel Panic). Daarom is het verstandig om je oude kernel nooit weg te gooien als je een nieuwe bakt.

[anoniem]

ik bouw mijn eigen kernel rpm's. Zelf heb ik kernel 2.6.11 in rpm gebouwd, wel volgens een how-to Ik heb geen enkel probleem ondervonden

[anoniem]

[quote:fe7cc9af9a="windowsXP-PRO"]ik bouw mijn eigen kernel rpm's. Zelf heb ik kernel 2.6.11 in rpm gebouwd, wel volgens een how-to Ik heb geen enkel probleem ondervonden[/quote:fe7cc9af9a] Gaat dat net zo makkelijk als in Debian? make menuconfig make-kpkg clean make-kpkg kernel_image dpkg -i jouweigenkernel.deb

[anoniem]

eh, nee heel anders in dit geval

[anoniem]

Erm, jongens, de OP had vragen over [b:d2ab86113d]zelf modules schrijven[/b:d2ab86113d], als hij dat beoogd neem ik aan dat hij al weet hou een kernel gecompileerd moet worden. Aan de OP, ik zou een boek aanschaffen, bijvoorbeeld [i:d2ab86113d]Linux device drivers[/i:d2ab86113d], daar staan waarschijnlijk antwoorden op je vragen en veel toekomstige vragen in: http://www.oreilly.com/catalog/linuxdrive3/

[anoniem]

[quote:2ba63dc1c0="Pinky & The Brain"]Ik heb nog nooit een eigen kernel gemaakt of zelfstandig kernelmodules geladen etc., maar dat lijkt me een overkoombaar probleem. [/quote:2ba63dc1c0] Ehhh nou Daniel ..... :roll:

[anoniem]

Hmmm, excusez-moi, ik moet mijn veronderstellingen bijstellen ;).

[anoniem]

Dus Pinky & The Brain zou je niet eerst eens een maandje lang allerlei kernels gaan bakken voordat je kernel-modules gaat schrijven. Want dit komt natuurlijk een beetje raar over :roll:

[anoniem]

[quote:8cae998236="danieldk"]Erm, jongens, de OP had vragen over [b:8cae998236]zelf modules schrijven[/b:8cae998236], als hij dat beoogd neem ik aan dat hij al weet hou een kernel gecompileerd moet worden. Aan de OP, ik zou een boek aanschaffen, bijvoorbeeld [i:8cae998236]Linux device drivers[/i:8cae998236], daar staan waarschijnlijk antwoorden op je vragen en veel toekomstige vragen in: http://www.oreilly.com/catalog/linuxdrive3/[/quote:8cae998236] OP ? Oorspronkelijke Poster ? wat betekend die afkorting ? Dat boek lijkt me idd wel een welkome hulp, ik was hem ook al eerder tegengekomen. Ook had ik me al een beetje ingelezen, maar een goed naslagwerk is natuurlijk altijd een goede hulp ! [quote:8cae998236] Hmmm, excusez-moi, ik moet mijn veronderstellingen bijstellen ;). [/quote:8cae998236] HA ha ha, sorry :oops: Maar het lijkt me dat kernels bakken niet supper moeilijk is, gewoon een kwestie van goed lezen en het proces doorgronden...dan is het in het vervolg piece of cake en het geeft je ook meer inzicht betreffende linux / besturigssystemen. [quote:8cae998236] Dus Pinky & The Brain zou je niet eerst eens een maandje lang allerlei kernels gaan bakken voordat je kernel-modules gaat schrijven. Want dit komt natuurlijk een beetje raar over :roll: [/quote:8cae998236] Hoezo raar ? En waarom een maandje kernels bakken ? Het lijkt me een leuke uitdaging om een eigen kernelmodule te schrijven die kan interfacen tussen een device en mijn eigen code. Het is wel lastig, maar goed te doen....al zal het in het begin veel moeite kosten. Het is ontzettend leerzaam, interessant en opent nieuwe werelden ;-). Ik begrijp dus niet helemaal waarom dit raar zou overkomen...ik ken zat programeurs die bijna niks van computersystemen af weten en slechts met enkele softwarepakketen weten te werken. Zelf wil ik echter weten hoe alles in elkaar steekt en werkt, anders kun je in mijn ogen ook nooit goed worden. Daarnaast is het ontzettend leuk en kun je ook eens iets thuis in elkaar knutselen :lol:. P&B

[anoniem]

Aan een kernel bakken is inderdaad niks aan, in vergelijking met het schrijven van modules. Om modules te schrijven moet je toch ietwat benul hebben van de werking van de kernel, dwz je moet je weg goed vinden in de header files en de datastructuren die daar gedeclareerd worden goed begrijpen. Ik zou dan ook een goed en vooral recent boek kopen, want tussen de kernel versies 2.2.x, 2.4.x en 2.6.x zit toch een aanzienlijk verschil in de manier waarop modules geschreven worden. Ik heb ooit eens kernel modules voor 2.6.x geschreven m.b.v. een verouderd boek dat voor kernels 2.2.x geschreven was, en dat was geen lachertje. Enige voorzichtigheid is ook gewenst, want je gaat heel low level programmeren. Je kan voor zover ik me kan herinneren elke variabele in kernel space manipuleren dus je kan je systeem zo op zn bek krijgen als je iets fout doet, en dat vind ik persoonlijk een zwakte van linux (alhoewel ik niet weet of andere kernels op dat gebied beter zijn).

[anoniem]

[quote:01d8ffd486="Bamboe"]Aan een kernel bakken is inderdaad niks aan, in vergelijking met het schrijven van modules. Om modules te schrijven moet je toch ietwat benul hebben van de werking van de kernel, dwz je moet je weg goed vinden in de header files en de datastructuren die daar gedeclareerd worden goed begrijpen. Ik zou dan ook een goed en vooral recent boek kopen, want tussen de kernel versies 2.2.x, 2.4.x en 2.6.x zit toch een aanzienlijk verschil in de manier waarop modules geschreven worden. Ik heb ooit eens kernel modules voor 2.6.x geschreven m.b.v. een verouderd boek dat voor kernels 2.2.x geschreven was, en dat was geen lachertje. [/quote:01d8ffd486] Dus een kernel module die je voor een 2.2.X systeem hebt gemaakt kun je niet op een 2.2.X toepassen ? Dat is wel even vervelend, want dan zou je voor elk systeem dus weer de source moeten aanpassen en is de onderlinge uitwisselbaarheid klein :-(. Hoe zit eht dan met kleine versie verschullen in de zelfde kernel ? kan dat ook problemen opleveren dan ? [quote:01d8ffd486] Enige voorzichtigheid is ook gewenst, want je gaat heel low level programmeren. Je kan voor zover ik me kan herinneren elke variabele in kernel space manipuleren dus je kan je systeem zo op zn bek krijgen als je iets fout doet, en dat vind ik persoonlijk een zwakte van linux (alhoewel ik niet weet of andere kernels op dat gebied beter zijn).[/quote:01d8ffd486] Dat is volgens mij helemaal geen nadeel wat aan de linux kernel kleeft, maar aan bijna alle kernels ? Zelfs windows NT heeft dat probleem. Je moet een afweging maken tussen snelheid en stabiliteit. Vroeger waren bijvoorbeeld die eerste windows NT versies volgens mij bijna alles buiten de kernel, maar dat maakte het systeem ontzettend traag. Om het geheel sneller te krijgen worden vele belangrijke zaken terug in de kernel geplaatst, maar dat gaat wel weer ten koste van de stabiliteit..., want er zijn meer kritische onderdelen waar het systeem fatale fouten kan maken. Het geldt dus voor bijna alle OS'es denk ik dus. Dat ik hier nu zelf met kernel modules ga experimenteren...tja, dat maakt het pas echt gevaarlijk ;-). Maar los van het feit dat het zaakje zeer instabiel kan worden door mijn onervarenheid.....ik loop dan toch geen risico op het beschadigen van de hardware of overige onderdelen van mijn systeem zoals data verlies ? Dat kan ik me namelijk niet permiteren ! P&B

[anoniem]

Je loopt alleen kans op een kernel panic ;)

[anoniem]

[quote:096cbb15a3="Pinky & The Brain"][quote:096cbb15a3="Bamboe"]Aan een kernel bakken is inderdaad niks aan, in vergelijking met het schrijven van modules. Om modules te schrijven moet je toch ietwat benul hebben van de werking van de kernel, dwz je moet je weg goed vinden in de header files en de datastructuren die daar gedeclareerd worden goed begrijpen. Ik zou dan ook een goed en vooral recent boek kopen, want tussen de kernel versies 2.2.x, 2.4.x en 2.6.x zit toch een aanzienlijk verschil in de manier waarop modules geschreven worden. Ik heb ooit eens kernel modules voor 2.6.x geschreven m.b.v. een verouderd boek dat voor kernels 2.2.x geschreven was, en dat was geen lachertje. [/quote:096cbb15a3] Dus een kernel module die je voor een 2.2.X systeem hebt gemaakt kun je niet op een 2.2.X toepassen ? [/quote:096cbb15a3] Je bedoelt waarschijnlijk in één van de gevallen 2.6.x ipv 2.2.x. Jep dat klopt inderdaad. Langs de ene kant is dat positief, omdat slechte interfaces van oude kernels vervangen worden door betere, maar het gaat ten koste van compatibiliteit. [quote:096cbb15a3] Dat is wel even vervelend, want dan zou je voor elk systeem dus weer de source moeten aanpassen en is de onderlinge uitwisselbaarheid klein :-(. [/quote:096cbb15a3] Ja, als je de kernel ontwikkeling een beetje volgt weet je dat er constant werk verricht wordt om drivers die voor 2.6.x geschreven worden te "backporten" naar 2.4.x, en elke keer er een nieuwe ontwikkelingsbranch wordt gestart (met oneven minor number), ontstaat dit probleem weer. Als men nu bv. een 2.7.x ontwikkelingsbranch start, gaan driver ontwikkelaars zich focussen op de nieuwe driver interface en moet er nadien weer veel gebackport worden. Dat is één van de redenen waarom de start van die branch zo lang mogelijk uitgesteld wordt en waarom er soms nog redelijk grote veranderingen binnen de 2.6.x kernel doorgevoerd worden, wat dan weer ten koste gaat van stabiliteit. [quote:096cbb15a3] Hoe zit eht dan met kleine versie verschullen in de zelfde kernel ? kan dat ook problemen opleveren dan ? [/quote:096cbb15a3] In principe niet, maar in praktijk zie je dat hier ook problemen optreden. Dat zie je bv. met nvidia drivers die het soms niet meer doen als er een nieuwe 2.6.x vrijgegeven wordt. (door de veranderingen in 2.6.x waar ik het hierboven al over heb gehad). Maar deze problemen zijn aanzienlijk kleiner dan bij "grotere" kernel releases (2.4 vs 2.6 dus) [quote:096cbb15a3] [quote:096cbb15a3] Enige voorzichtigheid is ook gewenst, want je gaat heel low level programmeren. Je kan voor zover ik me kan herinneren elke variabele in kernel space manipuleren dus je kan je systeem zo op zn bek krijgen als je iets fout doet, en dat vind ik persoonlijk een zwakte van linux (alhoewel ik niet weet of andere kernels op dat gebied beter zijn).[/quote:096cbb15a3] Dat is volgens mij helemaal geen nadeel wat aan de linux kernel kleeft, maar aan bijna alle kernels ? Zelfs windows NT heeft dat probleem. Je moet een afweging maken tussen snelheid en stabiliteit. Vroeger waren bijvoorbeeld die eerste windows NT versies volgens mij bijna alles buiten de kernel, maar dat maakte het systeem ontzettend traag. Om het geheel sneller te krijgen worden vele belangrijke zaken terug in de kernel geplaatst, maar dat gaat wel weer ten koste van de stabiliteit..., want er zijn meer kritische onderdelen waar het systeem fatale fouten kan maken. Het geldt dus voor bijna alle OS'es denk ik dus. [/quote:096cbb15a3] Ja, de beroemde monolitische- versus microkernel discussie. Het zou inderdaad flink schelen in performantie als de kernel constant in de gaten moet houden wie er aan welke variabelen komt, maar toch heb ik het gevoel dat het beter moet kunnen dan het nu is. Zo wordt er voor zover ik weet geen gebruik gemaakt van de features die C biedt om variabelen te beschermen. Je kan variabelen aanspreken die niet eens gedeclareerd zijn in de kernel headers die je include, en de kernel zal dan "at run time" de variabele opzoeken en je module er toegang tot geven. Ik geloof zelfs dat je op die manier zelfs aan de typecontrole van de C compiler ontsnapt. [quote:096cbb15a3] Dat ik hier nu zelf met kernel modules ga experimenteren...tja, dat maakt het pas echt gevaarlijk ;-). Maar los van het feit dat het zaakje zeer instabiel kan worden door mijn onervarenheid.....ik loop dan toch geen risico op het beschadigen van de hardware of overige onderdelen van mijn systeem zoals data verlies ? Dat kan ik me namelijk niet permiteren ! P&B[/quote:096cbb15a3] Zo'n vaart zal het wel niet lopen, maar in theorie kan het natuurlijk als je gaat prullen met IDE drivers , file systems en dergelijk.

[anoniem]

tja kenel panic :roll: [code:1:53c51315bb]~]$ uname -r 2.6.11-1.773_FC3_EA [/code:1:53c51315bb] die hebben volgens mij nog maar weinig mensen die Core 3 hebben. Ik heb hem zelf gekookt Van een kernel panic is hier GEEN sprake, systeem staat 24/7 aan. ik heb gisteren een kernel 2.6.11 gebakken met patch 2.6.11.7 erin. Nog niet geinstalleerdt, maar goed. Nee, kernels bakken is leuk, leerzaam, en je kan zelf bepallen wat de ingredienten zijn. Evert

[anoniem]

Oké, ik heb mijn eerste kernel gecompiled en toegevegd aan lilo gister. Het heeft me bijna de hele dag gekost, want ik ben elke optie stap voor stap langsgegaan en heb alles gelezen :lol:. Vervolgens duurde het compilen erg lang op mijn systeem :oops:. De kernel is op zich goed en start zonder problemen, maar er dienen nog wel enkele dingen worden veranderd, want mijn framebuffer staat nu op 640x480 o.i.d. en er komen enkele modprobe errors voorbij. Het vreemdste is nog wel dat de kernel groter is dan mijn oorspronkelijke kernel, maar toch aanzienlijk sneller boot ! Mooiste is misschien nog wel dat APM nu ook werkt ! :) Probleempje waar ik nu mee zit is de volgende...als ik nu met deze nieuwe aangepaste kernel boot...dan kan ik waarschijnlijk geen startx doen, want ik hem de nvidiadrivers nog niet geinstalleerd. Als ik zonder deze driver x zou starten krijg ik denk ik een foutmelding, maar kunnen acties als x starten ook gevolgen hebben voor mijn systeem als ik weer met de oude kernel start ? Nu moet ik natuurlijk de nvidiadriver ook in deze kernel zetten, maar pakt de nvidia-driver-installer automatisch de huidige kernel ? Of pakt hij de kernel die onder /usr/src/linux staat ? Ik heb namelijk nog geen link gemaakt naar die nieuwe kernel, dus /usr/src/linux verwijst nu nog nar de oorspronkelijke kernel denk ik. Kan de nvidia-installer hier wel mee overweg ? P&B

[anoniem]

[quote:fcde3b6466="Pinky & The Brain"]Nu moet ik natuurlijk de nvidiadriver ook in deze kernel zetten, maar pakt de nvidia-driver-installer automatisch de huidige kernel ? [/quote:fcde3b6466] De [url=http://www.nvidia.com/object/linux_display_ia32_1.0-7174.html]nvidia-driver-installer[/url] wordt standaard geïnstalleerd in de actieve kernel. De kernel versie waarmee je pc hebt opgestart dus. Alle nvidia drivers geïnstalleerd in andere kernel versies worden daarbij automatische verwijderd. Is dat niet de bedoeling, dan cd je eerst naar de map van de nvidia driver in /lib/modules/<kernel versie>/kernel/drivers/video en maak je een back-up van die nvidia module. Bijvoorbeeld voor kernel versie 2.6.x [code:1:fcde3b6466] cp nvidia.ko nvidia.ko.backup [/code:1:fcde3b6466][Enter] [quote:fcde3b6466="Pinky & The Brain"]Ik heb namelijk nog geen link gemaakt naar die nieuwe kernel, dus /usr/src/linux verwijst nu nog nar de oorspronkelijke kernel denk ik. Kan de nvidia-installer hier wel mee overweg ? [/quote:fcde3b6466] De nvidia-installer heeft de link in /usr/src niet nodig. De nvidia-installer gebruikt de links in de /lib/modules/<kernel versie> van de kernel waarmee je pc hebt opgestart. Tenzij je via een commandline option een andere kernel-source opgeeft, dan de kernel versie waarmee je pc hebt opgestart. Lees voor verdere info de [url=ftp://download.nvidia.com/XFree86/Linux-x86/1.0-7174/README.txt]nvidia readme.[/url]

[anoniem]

[quote:72d16347da="jolo"]De [url=http://www.nvidia.com/object/linux_display_ia32_1.0-7174.html]nvidia-driver-installer[/url] wordt standaard geïnstalleerd in de actieve kernel. De kernel versie waarmee je pc hebt opgestart dus. Alle nvidia drivers geïnstalleerd in andere kernel versies worden daarbij automatische verwijderd. Is dat niet de bedoeling, dan cd je eerst naar de map van de nvidia driver in /lib/modules/<kernel versie>/kernel/drivers/video en maak je een back-up van die nvidia module. Bijvoorbeeld voor kernel versie 2.6.x [code:1:72d16347da] cp nvidia.ko nvidia.ko.backup [/code:1:72d16347da][Enter] [/quote:72d16347da] Dat is dan erg onhandig dus ! Dan kun je namlelijk met slechts 1 kernel de nvidiadrivers gerbruiken ! Of is het toch mogelijk om die backup weer in de oorspronkelijke kernel terug te plaatsen ? Waarom verwijderd de installer überhaupt die nvida-module uit de oorspronkelijke kernel ? Ik kan me niet voorstellen dat het problemen geeft om de driver in meerdere kernels te compilen, aangezien je toch slechts 1 kernel per keer kunt booten ? [quote:72d16347da] De nvidia-installer heeft de link in /usr/src niet nodig. De nvidia-installer gebruikt de links in de /lib/modules/<kernel versie> van de kernel waarmee je pc hebt opgestart. Tenzij je via een commandline option een andere kernel-source opgeeft, dan de kernel versie waarmee je pc hebt opgestart. Lees voor verdere info de [url=ftp://download.nvidia.com/XFree86/Linux-x86/1.0-7174/README.txt]nvidia readme.[/url][/quote:72d16347da] Oké, dat is duidelijk al vindt ik het toch nog wel een beetje vreemd dat je slechts 1 kernel met de nvidiadriver kunt compilen. P&B

[anoniem]

Het probleem is waarschijnlijk dat je verschillende kernels hebt met hetzelfde versienummer die toch dezelfde module directory gebruiken. Bv. de 2.6.10 kernel die bij slackware geleverd wordt en je eigen 2.6.10 kernel. Doordat deze met een verschillende kernelconfiguratie werden gecompileerd kan het effectief gebeuren dat modules voor de ene 2.6.10 kernel niet gaan werken op de andere 2.6.10 kernel. In principe zou je in zo'n situatie heel de oude module directory moeten backuppen (mv /lib/modules/2.6.10 /lib/modules/2.6.10old bv.) en een nieuwe zooi modules moeten aanmaken met het commando "make modules; make modules_install" in de source tree van de kernel, en vervolgens de nvidia driver opnieuw installeren. Als de oude kernel weer wil booten zal je er wel weer voor moeten zorgen dat in /lib/modules/2.6.10 ook weer de oude modules staan (die je eerder gebackupt hebt), m.a.w. het blijft omslachtig. Met verschillende kernel versies is dit alles geen probleem, je kan perfect een 2.6.10 en een 2.6.11 kernel naast elkaar hebben, deze zullen dan hun eigen subdirectory in /lib/modules gebruiken voor hun modules. Mij lijkt het dus het makkelijkste om gewoon even de broncode van de laatste kernel af te halen van ftp.kernel.org, te compileren, make modules && make modules install uitvoeren (hiermee wordt gelijk een nieuwe subdirectory in /lib/modules aangemaakt), en nadat je de nieuwe kernel geboot hebt kan je dan zonder problemen de nvidia drivers opnieuw installeren en X starten. Ohja, uit wat ik lees van je vorige reactie blijkt dat je geen onderscheid maakt tussen de kernel en de modules/drivers, maar dat onderscheid is er dus wel degelijk. De nvidia driver wordt als module gecompileerd en wordt dus niet mee in de kernel gebakken, dat is een groot verschil!

[anoniem]

[quote:a3f7844d28="Bamboe"]Het probleem is waarschijnlijk dat je verschillende kernels hebt met hetzelfde versienummer die toch dezelfde module directory gebruiken. Bv. de 2.6.10 kernel die bij slackware geleverd wordt en je eigen 2.6.10 kernel. Doordat deze met een verschillende kernelconfiguratie werden gecompileerd kan het effectief gebeuren dat modules voor de ene 2.6.10 kernel niet gaan werken op de andere 2.6.10 kernel. In principe zou je in zo'n situatie heel de oude module directory moeten backuppen (mv /lib/modules/2.6.10 /lib/modules/2.6.10old bv.) en een nieuwe zooi modules moeten aanmaken met het commando "make modules; make modules_install" in de source tree van de kernel, en vervolgens de nvidia driver opnieuw installeren. Als de oude kernel weer wil booten zal je er wel weer voor moeten zorgen dat in /lib/modules/2.6.10 ook weer de oude modules staan (die je eerder gebackupt hebt), m.a.w. het blijft omslachtig. Met verschillende kernel versies is dit alles geen probleem, je kan perfect een 2.6.10 en een 2.6.11 kernel naast elkaar hebben, deze zullen dan hun eigen subdirectory in /lib/modules gebruiken voor hun modules. Mij lijkt het dus het makkelijkste om gewoon even de broncode van de laatste kernel af te halen van ftp.kernel.org, te compileren, make modules && make modules install uitvoeren (hiermee wordt gelijk een nieuwe subdirectory in /lib/modules aangemaakt), en nadat je de nieuwe kernel geboot hebt kan je dan zonder problemen de nvidia drivers opnieuw installeren en X starten. [/quote:a3f7844d28] Als ik je goed begrijp gaat het installeren van de nvidiadrivers helemaal geen problemen opleveren voor mijn oorspronkelijke kernel dan ? Ik had namelijk de slackware 2.4.26 geloof ik en gistermorgen heb ik fan kernel.org de 2.4.30 gehaald. Deze heeft dus een ander versienummer en zou zijn modules dus ook in een eigen subdir plaatsen ? Dan zou het dus geen problemen mogen opleveren en kan ik gewoon met beide kernels de nvidiadriver gebruiken ? [quote:a3f7844d28] Ohja, uit wat ik lees van je vorige reactie blijkt dat je geen onderscheid maakt tussen de kernel en de modules/drivers, maar dat onderscheid is er dus wel degelijk. De nvidia driver wordt als module gecompileerd en wordt dus niet mee in de kernel gebakken, dat is een groot verschil![/quote:a3f7844d28] En toch ook weer niet, want volgens mij is de nvidia driver een LKM en dus in dat geval gewoon onderdeel van de kernel...alleen maakt hij geen deel uit van de base-kernel ;-). P&B