Ga naar inhoud
  • 0

Kernel geneuzel


anoniem

Vraag

Aanbevolen berichten

  • 0
Ehm, eventjes een vraagje... Als je een nieuwe kernel maakt....bijvoorbeeld overstappen van 2.4 naar 2.6. Moet je dan ook je zelf gecompileerde modules aanpassen ? Een paar dagen geleden heb ik namelijk de NVIDIA drivers geinstalleerd, die werden op basis van mijn kernel gecompileerd. Dus ik neem aan dat je deze dan opnieuw moet doen, want je kernel verander dan nogal...of wordt dit automatisch aangepast tijdens de kernel compilatie ?
Link naar reactie
  • 0
Die moet je idd aanpassen. Ik dacht dat de 2.6 kernel wel een optie heeft om modules van een oudere kernel geforceerd te laden, maar in hoeverre dat werkt weet ik niet. Als je een kernel-module compileert, worden de zogenaamde kernel-headers gecheckt. Daarmee wordt de compeling gemaakt tussen jouw module en de kernel (zoiets ongeveer). En wanneer een nieuwe kernel? Als ik op de gentoo-forums weer eens iets leuks tegenkom, wat nog niet standaard in de kernel zit. Bv logo'tje van Gentoo bovenin beeld bij het booten. Ik heb ook wel eens geprobeerd packet-writing aan de praat te krijgen voor de 2.4 kernel, maar mijn brander werkte niet mee. En af en toe een harde reset als mijn toetsenbord vast zit. het is een stand-alone bakje, dus dan resteert niet anders.
Link naar reactie
  • 0
[quote:80b13b4bc1="water"]Die moet je idd aanpassen. Ik dacht dat de 2.6 kernel wel een optie heeft om modules van een oudere kernel geforceerd te laden, maar in hoeverre dat werkt weet ik niet. Als je een kernel-module compileert, worden de zogenaamde kernel-headers gecheckt. Daarmee wordt de compeling gemaakt tussen jouw module en de kernel (zoiets ongeveer). [/quote:80b13b4bc1] Oké, bedankt...ik dacht wel dat het zo zat... De Microkernel, ik neem aan dat je hurd bedoeld. Nou dat is aan mij voorlopig niet besteed...het lijkt wel mooi, maar ik heb nog nooit een eigen kernel gecompileerd en ik ben al zeer content met mijn huidige systeem :D.
Link naar reactie
  • 0
met de microkernel word niet enkel hurd bedoeld, er zijn meer kernels waaronder die van NextStep. ik ben het mbt de kernel wel met pascal eens, buiten het feit dat mij wel iets meer nut van de microkernel naar binnen schiet is een microkernel een complex gedrocht waar je liever niet zelf aan wil zitten. complexe gedrochten zijn fout gevoeliger. fouten gaan ten kosten van stabiliteit, veiligheid e.d. Ik ben daarom ook een voorstander van de Linux kernel die er nu is: Monolyth met microkernel trekjes (modulair). Wanneer je reboot hoeft voor een desktop geen zak uit te maken. Dat mensen geilen op uptimes is prima.. maar doe dat dan met een dikke proliant servero id voor je en niet je huis/tuin/keuken desktopje met een uptime van 100 dagen. >99.9% stabiliteit is iets voor servers, en met name productiebakken zoals database/financiele systemen. Iets wat mission critical is zoals de Gnu/Linux cluster van de zwitserse bank die de financiele transacties afhandeld. Verder moet een desktop <relatief> veilig zijn als het om inbraakgevoeligheid gaat. De mensen die elke week hun kernel patchen van hun desktop omdat ze anders bang zijn dat ze gehacked kunnen worden vind ik altijd een toppunt van overdrijven.
Link naar reactie
  • 0
Hmmm ja ook ik een wel een aantal voor en nadelen van een microkernel om maar er eens een paar te noemen [b:6c951b683f]voordelen[/b:6c951b683f] - Een vastlopend process hangt niet meteen het hele kernel op vastlopers tengevolge van slecht programeerwerk hoor je echter te vermijden, en kunnen zo ook niet voorkomen worden - goede controlle over de executie tijd, van belang bij realtime processen, maar ja wie draait er nu true hard realtime toepassingen. - erg geschikt voor multiprocessor systemen (denk aan AIX,en Solaris) elke thread kan tenslote zijn eigen kernelmemory gebruiken, geen moeilijk gedoe met spinlocks meer - Eenvougere code..... zegt men, zie verder [b:6c951b683f]Nadelen[/b:6c951b683f] - meer overhead de taakscheduler moet de kerneltaken apart schedulen, dat kost tijd en geheugen, dus vertragend - Complexere overhead, de kernelcode lijkt zoals gezecht eenvoudiger, maar om het geheel te cooordineren is een relatief ingewikkeld systeem nodig. - Voordelen zijn in een average omgeving niet van toepassing - Ondanks ogenschijnlijk eenvoudigere code tamelijk ingewikkeld te ontwkkelen en nog veel meer voor en nadelen. Ik denk dat Linus net als Andrew de juiste koers heeft gevolgt Linux omdat hij een leuk systeempje voor thuis wilde, Andrew omdat hij zijn mensen wilde voorbereiden op het grote werk. Dat PC's zo krachtig zouden worden konden beiden ook niet weten.
Link naar reactie
  • 0
[quote:221670fe74="Tekkie"]Het is wel zo dat in de monolitische opzet alle drivers meegroeien / meegetest worden met de kernel (m.u.v. bepaalde binary modules..). In een microkernel kan een slecht geprogrammeerde device driver de kernel net zogoed ophangen (BSOD anyone?)[/quote:221670fe74] Nee, een in-kernel driver heeft toegang tot de volledige kernel (en volledige) address space, een bij een goedgeschreven microkernel heeft het alleen beperkte toegang. En over BSDODs, de Windows NT kernel is [b:221670fe74]geen[/b:221670fe74] microkernel. Ik denk alleen dat we (voorlopig?) geen grote opkomst van de microkernel op zien komen. Niet door technologische selectie, maar systemen met monolitische kernels hebben simpelweg een veel groter deel van de markt in handen. Bovendien is er veel meer traditie. Persoonlijk zou ik me er niet te druk maken over monolithic- vs microkernel. Kernels zijn tegenwoordig behoorlijk stabiel, erg snel, portable en vrijwel allemaal ook SMPable. In de toekomst is userland veel belangrijker...
Link naar reactie
  • 0
[quote:ae5e7cd45b="danieldk"]Het stomme is dat het het wel heel even geweest is (iig close to), maar daarna heeft het management besloten dat een deel van het grafische werk maar naar kernel mode moest, omdat dat sneller is. Maja, de gevolgen kennen we, dat kan mooi in 1 klap de boel op z'n bek gooien ;).[/quote:ae5e7cd45b] dat was vanaf NT3.65 omdat ze erachter kwamen dat het switchen van ring0 naar ring3 te traag ging :P
Link naar reactie
  • 0
Omdat er niet zoveel geneuzeld meer werd maar wat geneuzelnieuws. /. meldt dat er geen 2.7 branch komt, en dat de 2.6 gewoon verder ontwikkeld wordt. Mijns inziens een slecht idee omdat er dan niet echt grote stappen uitgekristaliseert kunnen worden. Ik neem aan dat je de ene 2.6 kernel niet incompatible wil maken met de volgende 2.6 kernel. Ook wordt je vanaf nu denk bedolven onder de -testing en -rc versies.
Link naar reactie
  • 0
[quote:d9b4bc231a="erikvernooy"]Omdat er niet zoveel geneuzeld meer werd maar wat geneuzelnieuws. /. meldt dat er geen 2.7 branch komt, en dat de 2.6 gewoon verder ontwikkeld wordt. Mijns inziens een slecht idee omdat er dan niet echt grote stappen uitgekristaliseert kunnen worden. Ik neem aan dat je de ene 2.6 kernel niet incompatible wil maken met de volgende 2.6 kernel. Ook wordt je vanaf nu denk bedolven onder de -testing en -rc versies.[/quote:d9b4bc231a] Voorlopig althans De ontwikkeling focust zich voorlopig op de 2.6-kernel, en daar is niets mis mee. Pas als de 2.6-kernel voldoende kwaliteit heeft, zal men zich gaan richten op geheel nieuwe features. MS doet inmiddels hetzelfde. Longhorn wordt uitgesteld behoeve van servicepacks voor Windows XP
Link naar reactie
  • 0
[i:0013e46d3a]"Andrew's vision, as expressed at the summit, is that the mainline kernel will be the fastest and most feature-rich kernel around, but not, necessarily, the most stable. Final stabilization is to be done by distributors (as happens now, really), but the distributors are expected to merge their patches quickly."[/i:0013e46d3a] :o :o
Link naar reactie
  • 0
Laten we hopen dat dat niet Linus' visie is. Ik had ook al wel ergens gelezen dat ze minder drastische wijzigingen gingen aanbrengen bij elke major versie, zodanig dat je een snellere development kreeg. Dus minder ingrijpende wijzigingen tussen 2.6.x en 2.8.x, zodanig dat 2.8.x sneller stabiel zou zijn. Tot hiertoe duurde de ontwikkelingscyclus meer dan 2 jaar voor een major versie. Bij KDE zijn ze ook die richting uit aan't gaan, weinig grote veranderingen tussen KDE 3.2 en KDE 3.3.
Link naar reactie
  • 0
[quote:89daa9b188="water"] Voorlopig althans De ontwikkeling focust zich voorlopig op de 2.6-kernel, en daar is niets mis mee. Pas als de 2.6-kernel voldoende kwaliteit heeft, zal men zich gaan richten op geheel nieuwe features. [/quote:89daa9b188] Nee, de toon is anders. Redelijk grote veranderingen die vroeger na een oneven versie zouden gaan, gaan nu eerst tijdelijk in Morton's branch, daarna direct in 2.4.x. De stabiele branches zouden meer nieuwe features moeten gaan krijgen, en de distributeurs moeten zelf een gepatchte kernel leveren voor stabiliteit. Dat staat in alle grote nieuwsbronnen en de LKML.
Link naar reactie

Doe mee aan dit gesprek

Om te reageren, moet je eerst inloggen. Dit doe je door rechtsboven op inloggen te klikken.

Gast
Antwoord op deze vraag...

×   Geplakt als verrijkte tekst.   Plak in plaats daarvan als platte tekst

  Er zijn maximaal 75 emoji toegestaan.

×   Je link werd automatisch ingevoegd.   Tonen als normale link

×   Je vorige inhoud werd hersteld.   Leeg de tekstverwerker

×   Je kunt afbeeldingen niet direct plakken. Upload of voeg afbeeldingen vanaf een URL in

×
×
  • Nieuwe aanmaken...