Kernel geneuzel

[anoniem]

Lekker slap lullen over het kernel zodat Bilbo zijn thread weer on topic blijft. Goed kernel updates waaarom ? enne een microkernel waarom ? reboots waneer ? brand los.

[anoniem]

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 ?

[anoniem]

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.

[anoniem]

[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.

[anoniem]

Microkernel? -> Handiger voor SMP. We hebben gezien hoe moeilijk is de hele kernel fine-grained locks te laten maken in monolithic kernels.

[anoniem]

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.

[anoniem]

include(kayjay) Was er laatst ergens niet iemand met een UpTime van 5jr of zo? Wat voor systeem heb je dan? 5 Jr is een eeuwigheid in computers.

[anoniem]

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.

[anoniem]

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?)

[anoniem]

klopt, dat meende ik minof meer ook al aangegeven te hebben.

[anoniem]

[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...

[anoniem]

Okee goed, mijn fout. NT heeft geen microkernel. http://www.microsoft.com/technet/prodtechnol/ntwrkstn/evaluate/featfunc/kernelwp.mspx

[anoniem]

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 ;).

[anoniem]

[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

[anoniem]

Wel bij de les blijven Tekkie, Blijken er onder de leken ook nopg diverse opvattingen over MicroKernel en Realtime (en vast overn mog veel meer dingen) te bestaan. tja.... als ik me daar ook nog mee moet gaan bezig houden.

[anoniem]

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.

[anoniem]

[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

[anoniem]

[i:f2af2d26d2] active development will now continue in the mainline 2.6 tree, and the final stabilization will be left up to the companies that provide Linux distributions[/i:f2af2d26d2] :o

[anoniem]

[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

[anoniem]

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.