Linux (Monoliittinen kerneli)
- Kernelin suuri koko. Kernelin kääntö kestää markkinoiden nopeimmillakin koneilla kolmisen päivää. Hitaammilla enemmän.
- Kaikki toiminnot sisälletetty kerneliin (mm. laitteiden ajurit)
- Virhe ajurin koodissa voi aiheuttaa systeemin kaatumisen. Kernel Panic tulee hyvin tutuksi.
- Uuden ajurin asennus tai poistaminen vaatii kernelin uudelleenkääntämisen.
- LINUX ohjelmat ajetaan prosesseina, jossa yksi prosessi ei voi puuttua toiseen prosessiin suoraan. Kunkin prosessin muistialue on suojattu toiselta prosessilta. Prosessit käyttävät "co-operative" – tyyppistä moniajo skedulointia. Tämä tarkoittaa, että kukin taski päättää itse, että milloin se luovuttaa ajovuoron seuraavalle. Siten virhe kernel-tason taskissa voi pahimmillaan jumiuttaa koneen.
- siinä huonosti käyttäytyvä rutiini voi kaataa koko järjestelmän.
- Käyttöjärjestelmään tulevat päivitykset tarkoittavat AINA uudelleenkäynnistystä.
Windows (mikrokerneli)
- Kerneli sisältää vain tärkeimmät ja on siten erittäin minimalistinen ja siten se on erittäin nopea, kevyt ja vakaa käytössä.
- Ajurit eivät ole sisälletetty kerneliin, joten virhe ajurin koodissa kaataa ainoastaan ajurin, ei koko käyttöjärjestelmää. Sama ohjelmissa. Ohjelman virheellinen toiminta kaataa ainoastaan ohjelman, ei koko järjestelmää.
- Käyttöjärjestelmään tulevat päivitykset eivät yleensä tarkoita uudelleenkäynnistystä ellei päivitys tule itse kerneliin, jolloin uudelleenkäynnistys on aina pakollinen. Uusi windows tosin tulee korjaamaan tämänkin, joten käytännössä se tarkoittaa entistä pitempiä uptime-tilastoja.
- Kernelin suuri koko. Kernelin kääntö kestää markkinoiden nopeimmillakin koneilla kolmisen päivää. Hitaammilla enemmän.
- Kaikki toiminnot sisälletetty kerneliin (mm. laitteiden ajurit)
- Virhe ajurin koodissa voi aiheuttaa systeemin kaatumisen. Kernel Panic tulee hyvin tutuksi.
- Uuden ajurin asennus tai poistaminen vaatii kernelin uudelleenkääntämisen.
- LINUX ohjelmat ajetaan prosesseina, jossa yksi prosessi ei voi puuttua toiseen prosessiin suoraan. Kunkin prosessin muistialue on suojattu toiselta prosessilta. Prosessit käyttävät "co-operative" – tyyppistä moniajo skedulointia. Tämä tarkoittaa, että kukin taski päättää itse, että milloin se luovuttaa ajovuoron seuraavalle. Siten virhe kernel-tason taskissa voi pahimmillaan jumiuttaa koneen.
- siinä huonosti käyttäytyvä rutiini voi kaataa koko järjestelmän.
- Käyttöjärjestelmään tulevat päivitykset tarkoittavat AINA uudelleenkäynnistystä.
Windows (mikrokerneli)
- Kerneli sisältää vain tärkeimmät ja on siten erittäin minimalistinen ja siten se on erittäin nopea, kevyt ja vakaa käytössä.
- Ajurit eivät ole sisälletetty kerneliin, joten virhe ajurin koodissa kaataa ainoastaan ajurin, ei koko käyttöjärjestelmää. Sama ohjelmissa. Ohjelman virheellinen toiminta kaataa ainoastaan ohjelman, ei koko järjestelmää.
- Käyttöjärjestelmään tulevat päivitykset eivät yleensä tarkoita uudelleenkäynnistystä ellei päivitys tule itse kerneliin, jolloin uudelleenkäynnistys on aina pakollinen. Uusi windows tosin tulee korjaamaan tämänkin, joten käytännössä se tarkoittaa entistä pitempiä uptime-tilastoja.
Vastaukset 46
Vanhimmat
Olisit ollut aivan ylivoimainen. Kukaan heistä ei pysyty tiivitämään samanpituiseen juttuun yhtä paljon valheita. Kerrassaan oivallinen saavutus.
Naama kiinni Ossi. Älä jaksa jauhaa paskaa linuxelitistihomo.
Kyllä sitä tuntee itsensä elitistiseksi kun ei tarvitse tapella jatkuvasti virusten, matojen ja muiden haitakkeiden kanssa levyneheyttämisen ja rekisterinsiivoamisen lomassa.
Homostelun jätän Windows-rahvaalle.
Ja Windowsissa ei ole minkäänlaista pakettimanageria.
Hihi, taitaa olla otsikoiden tekstit lipsahtanut väärin päin, eka teksti kertoo selvästi windowsista ja toinen linuxista ;)
Linux EI OLE MICROKERNEL!
Painakaa se paksuun kaaliinne.
Sittenhän minulla on vissiin joku yliluonnollisen nopea tietokone, jollaista ei vielä pitäisi olla olemassakaan. Asensin Gentoo Linuxin stage1:n, eli sellaisen linux-distron, jossa mahdollisimman paljon käännetään omalla koneella. Omistan tavallisen PC:n, jossa on 1,35 gigahetrsin prosessori ja muistia asennushetkellä oli 320 megaa. Gentoo asentui reilussa vuorokaudessa suhteellisen täysveriseksi järjestelmäksi. Aivan, kernelikin käännettiin itse.
Jotkut tykkää asentaa käyttöjärjestelmänsä tunnissa - toiset taas vuorokaudessa.
jotkut käynnistää tietokoneensa uudelleen kerran päivässä, jotkut kerran vuodessa.
Jotkut tykkää maksaa kauheita sähkölaskuja, jotkut taas ei. Ja aika paisuttelua tuo tunnissa bottaaminen. Minulla ei ole seonnut windows kuin kaksi kertaa tänä vuonna.
No eihän sitä pakko ole pitää aina päällä. Windows mokoma bootitaan joka ohjelman - ei pelkästään ajurin - asennuksen jälkeen, mitä ei voi jaksaa sietää, varsinkaan jos on paljon asennettavaa. Linux kernelin koko päivityksen jälkeen. Monet linuxin ominaisuudet voi kääntää kerneliin moduuleiksi (vrt. windowsin ajurit), eikä täten tarvitse odotella koneen uudelleenkäynnistymistä ;)
>Jotkut tykkää asentaa käyttöjärjestelmänsä tunnissa
Ja olet kokeillut että tuo toimii windowsin sorsista? :)
Saa Linuxinkin (puolessa) tunnissa asennettua, jos valitsee distroksi vaikka Ubuntun.
Eikös tässä puhuttu kernelin kääntämisestä ei linux distron asentamisesta koneeseen.
Tosin en ole tähän kernelin kääntämiseen niin perehtynyt, mutta parikertaa kokeillut kääntää ja semmosen 30-50 minuuttia vienyt. Tuntuu tuo 3 päivää vähän yliampuvalta.
Olis pitänyt lukee viesti loppuun.
Voi olla välillä ihan hyvä idea :)
miksi se kone pitää käynnistää uudelleen kerran vuodessa? Miksi niin usein?
Täsmennys windows-vammaisille:
Windows
Office
näytön ajurit
virustutka
PAKOLLISET virustutkan ja XP:n turvapäivitykset
tulostimen ajurit
työpöytäympäristöjä (windowsissa==explorer)
www servereitä ym kasoittain
ohjelmointiympäristöjä useampi
muutama peli
kuvankäsittelyohjelmia
webbiselaimia
3 kpl boottaatko-vielä-yhdesti,pelle -cd ei mene millään pc koneella alle tunnissa sisään.
Linuxilla taitaa tuo Gentoo olla ainoa distro, jonka koko asennus ei pääsääntöisesti mene 20-80 min haarukkaan. Ja Linuxia ei tarvitse sitten bootata kertaakaan kesken asennuksen.
Nytpä taisit kuitenkin hieman liioitella. Harvempi tarvitsee noista joka ikistä. Esimerkiksi pelaajalla ei välttämättä ole lainkaan toimisto-ohjelmien tarvetetta, yksi selain riittää, tietotaitoa ei omien pelien koodailuun riitä ja mihinpä sitä weppiserveriäkään tarvitsee, jos sellaista ei tarvitse?
Ei servereitä ja ohjelmointitarvikkeita ole pakko asentaa Linuxeissakaan.
Parhaimmillaan olen saanut Linuxin koneeseen n. 20 minuutissa, yksi uudelleenkäynnistys asennuksen jälkeen ja nettiin. Kokeile samaa windowsilla.
Uudelleenkäynnistys tarvitaan Macissa kaikkien päivitysten jälkeen.
Windowsissa ja Linuxissa uudelleenkäynnistys tarvitaan päivitysten jälkeen vain poikkeustapauksissa.
haittaohjelmien jakelijana.
http://en.wikipedia.org/wiki/Kernel_(computer_science)
Ja tiivistetty versio kielitaidottomille:
http://fi.wikipedia.org/wiki/Kernel
Kyllä tää oli ihan vaan tsoukki.
> - Kaikki toiminnot sisälletetty kerneliin (mm.
> laitteiden ajurit)
Väärin.
Ajurien binäärikoodin voi nykyään suoraan insertoida kerneliin dynaamisesti ladattavina moduuleina.
> - Uuden ajurin asennus tai poistaminen vaatii
> kernelin uudelleenkääntämisen.
Toisinpäin:
Uuden kernelin asennus vaatii kaikkien ajurien uudelleenkääntämisen.
> - LINUX ohjelmat ajetaan prosesseina, jossa yksi
> prosessi ei voi puuttua toiseen prosessiin
> suoraan. Kunkin prosessin muistialue on suojattu
> toiselta prosessilta. Prosessit käyttävät
> "co-operative" – tyyppistä moniajo skedulointia.
> Tämä tarkoittaa, että kukin taski päättää itse,
> että milloin se luovuttaa ajovuoron seuraavalle.
> Siten virhe kernel-tason taskissa voi
> pahimmillaan jumiuttaa koneen.
Väärin.
Linuxissa on täysin kernelin hallinnoima nykyisin HPET ajastimella tehty keskeyttävä skedulointi.
Normaaliprioriteetilla ajettavat ohjelmat eivät saa kuin normaalin quantumin verran suoritusaikaa jokainen.
Ainoastaan ns. realtime sovellukset tarvitsevat co-operative yield() -käskyä. Ja realtime sovelluksia ei userspacessa juuri ajeta, muuta kuin sulautetuissa järjestelmissä.
> - siinä huonosti käyttäytyvä rutiini voi kaataa
> koko järjestelmän.
Ei voi, jos se ajetaan normaalilla skeduloinnilla.
Huonosti käyttäytyvä softa kaataa itsensä, ja kerneli siivoaa sen pois. Muut softat ei tästä joudu kärsimään.
Ainoastaan realtime skeduloinnilla yksi softa voi kaataa systeemin. Mutta realtime skedulointia tarvitsee käyttää vain sulautetuissa järjestelmissä, tai userspace ajureissa. Eli tosi harvoin.
Loppupäätelmä Linuxista:
Muut Linuxista sanotut asiat pitävätkin paikkaansa. Huonosti tehty ajuri kaataa systeemin äärimmäisen helposti. Pahimmillaan voidaan räjäyttää kovalevyn data bittitaivaaseen.
Microkernelit ovat paljon monoliittisia kerneleitä parempia. Valitettavasti ei ole vielä moisia tuotantokäytössä paljoa käytetty, QNX:ää ja muutamaa muuta harvinaisuutta lukuunottamatta.
> Windows (mikrokerneli)
Väärin, tavallaan.
Windows NT 5.x, eli 2000:ssa ja XP:ssä käytetty, ei ole enää puhdas microkernel, vaan se on hybridi.
Siinä on mahdollista ajaa ajureita omina servereinään, mutta tämä on hidasta johtuen ylimääräisistä softa -> API -> kernel -> ajuri serveri -> kernel -> softa hypyistä.
Tämän takia on mm. GDI ja Direct X, joiden kautta hypyt menee about
softa -> API (-> DirectX tai GDI ajuri kernelissä)
kernel osio suluissa, koska monesti esim. DirectX kutsut eivät tarvitse kerneliä välissä, koska DirectX:än API osaa joissain tapauksissa käyttää laitteistoa suoraan. Monet DirectX/GDI näytönohjain ajurit Linuxin tapaan insertoidaan kerneliin, jolloin niiden huono käytös voi kaataa koko paskan ;)
> - Kerneli sisältää vain tärkeimmät ja on siten
> erittäin minimalistinen ja siten se on erittäin
> nopea, kevyt ja vakaa käytössä.
Osittain totta.
Vielä Windows NT 3.5:ssa oli kaikki ylimäärinen userspacessa omina servereinään.
Windows NT 4:sta lähtien integroitiin WINNT kerneliin mm. GDI (Graphics Device Interface) grafiikkarajapinta ja DirectX rajapinnat osittain kerneliin tehostamaan multimediasovelluksia.
Windows 2000 lähtien kerneliin tungettiin DirectX:ää varten yhä enemmän kernel rajapintoja, jotka siis käsittelevät laitteistoa suoraan. Puhukaamme eräänlaisista ajurien "kuorista", joiden kautta varsinaiset ajurit pystyvät käyttämään laitteistoa suoraan userspacesta ilman että tarvitaan väliin ylimääräisia kernel kutsuja.
> - Ajurit eivät ole sisälletetty kerneliin, joten
> virhe ajurin koodissa kaataa ainoastaan ajurin,
> ei koko käyttöjärjestelmää. Sama ohjelmissa.
> Ohjelman virheellinen toiminta kaataa ainoastaan
> ohjelman, ei koko järjestelmää.
Tämä pätee ainoastaan ei-multimedia ajureille. DirectX:än ja GDI:n rajapintoja palvelevat ajurit kyllä insertoidaan kerneliin monoliittiseen tapaan.
Tosin muut ajurit voikin sitten ajaa servereinä, ja niin monesti tehdäänkin esim. USB ja Firewire tahi verkkokorttiajureiden kanssa.
> - Käyttöjärjestelmään tulevat päivitykset eivät
> yleensä tarkoita uudelleenkäynnistystä ellei
> päivitys tule itse kerneliin, jolloin
> uudelleenkäynnistys on aina pakollinen. Uusi
> windows tosin tulee korjaamaan tämänkin, joten
> käytännössä se tarkoittaa entistä pitempiä
> uptime-tilastoja.
Näin teoriassa, mutta EI KÄYTÄNNÖSSÄ!
Windowsissa on nimittäin perseestä se, että tiedostoa ei voi kirjoittaa yli jos se on ladattu muistiin. Ns. Copy-on-write Executables toiminnallisuus on ilmeisesti turvallisuus syistä jätetty pois.
Täten jonkun kernel-ajurin tai serverin tiedostojen päivittäminen vaatii uudelleenkäynnistämisen. Myös monien ohjelmistojen osakomponenttien eli DLL:ien päivittäminen vaatii uudelleenkäynnistämisen, koska ne voi kirjoittaa yli uudemmilla versiolla vasta kun vanhat on poistettu käytöstä.
Loppusanat Windows NT sarjan kerneleistä:
Ihan hienoja kerneleitä, mutta en tajua miksi vitussa niiden nykyajan tehokkaiden koneiden aikakaudella pitää vielä integroida paljon userspaceen kuuluvaa toiminnallisuutta kerneliin.
Huonosti toimiva näytönajuri voi kaataa koko systeemin.
Windowsissa on tavallaan KERNEL PUOLELLA terveempi suunta kuin Linuxissa: micro/hybrid kerneli on tehokkaissa koneissa parempi kuin monoliittinen.
Mutta Windowsin userland on perseestä, ja tekee koko kernelin mahtavuuden turhaksi. Huono userland tekee juuri ne tietoturvaongelmat ja epävakauden, ei kerneli.
Tuo mikro/monoliittinen -kernel vertailu muistuttaa hieman risc/cisc vertailua. Käsittääkseni mikrokerneli ei kuitenkaan ole yksiselitteisesti kaikin puolin parempi, vaan siinäkin on omat ongelmansa. Mulle ihan sama kunhan toimii :)
Mikrokerneli on nykyajan yksiprosessorisilla CISC koneilla ongelmallinen.
CISC prossuilla context switch vie liikaa aikaa, koska prosessorissa on liian vähän rekistereitä pitämään prosessien kaikkia tilatietoja, joten joudutaan swäppäämään hitaan keskusmuistin kautta. Mikrokernelit ovat huomattavasti hitaampia CISC koneilla, kuin monoliittiset kernelit. Siksi esim NT-kerneli on "vain" hybridi monoliittisesta ja mikrokernelistä.
Kun tuo IBM:än Cell tulee, niin veikkaan monoliittisten kernelien kuolevan sukupuuttoon, kun kymmeniä rekisterejä omaava RISC CELL pystyy pitämään prosessien tilatiedot kokonaan nopeissa prosessorin sisäisissä rekistereissä.
Ja kun otetaan huomioon Cell arkkitehtuurin monet eri apuprosessorit, niin mikrokerneli on paljon tehokkaampi ja vakaampi. Säikeiden ja niiden käyttämien resurssien synkronointi on paljon helpompaa kuin monoliittisella kernelillä.
Applen PowerPC raudassa on RISC. Joten Mac OS X:än mikrokerneli palvelee tätä konseptia hyvin. Mikrokerneli saa lähes monoliittisen kernelin tehokkuuden, kun on tarpeeksi rekisterejä joiden kanssa leikkiä, näin lyhyesti tokaisten.
> Mikrokerneli on nykyajan yksiprosessorisilla CISC koneilla
> ongelmallinen.
Nojoo, mistäs tollasen väitteen repäisit? Jos vähän asiaan perehdyt niin esim AMD64 ja EMT64 (Intelin vastaava) kyllä mappaa kaikki CISC-käskyt sisäisesti RISC-käskyiksi. Loppua tosta en edes vaivaudu kommentoimaan.
> CISC prossuilla context switch vie liikaa aikaa, koska
> prosessorissa on liian vähän rekistereitä pitämään prosessien
> kaikkia tilatietoja, joten joudutaan swäppäämään hitaan
> keskusmuistin kautta.
Tästäkin taas paistaa asiaan perehtyneisyys ja asiantuntemus. Ensinnäkin taas x64:ssa on yleiskäyttöisiä rekistereitä 16 kpl, joten luulisi riittävän (UltraSPARC:ssa muistaakseni 32). Jos meinaan niitä käytettäisiin kontekstin vaihtoon kuten kuvailet.
Mitä järkeä tallentaa yleiskäyttöisiin rekistereihin mitään prosessikohtaisia tietoja kun sitä varten on esim. BSD:ssä struct proc (linuxin struct task) (joka sijaitsee kernelin muistialueella)?
Tuon lopputekstin voikin jättää omaan arvoonsa ottaen huomioon edelliset kommentit...
ksym_ finally met his match... : D
Tuohon context switchiin rekisterien kautta/avulla en ota kantaa koska en tiedä miten asia oikeasti on, mutta mitä CELL tulee muuttamaan? Johan hienoja RISC arkkitehtuureita on ollut pitkään eivätkä ne silti ole x86:sta syrjäyttäneet.
> Mitä järkeä tallentaa yleiskäyttöisiin
> rekistereihin mitään prosessikohtaisia tietoja
> kun sitä varten on esim. BSD:ssä struct proc
> (linuxin struct task) (joka sijaitsee kernelin
> muistialueella)?
Monoliittisissa kerneleissä itse kerneli tarjoaa KAIKKI laitteiston palvelut ohjelmille suoraan.
Nämä palvelut ovat niitä satoja softakeskeytyksillä toteutettuja funktioita, jotka suoritetaan joko omina säikeinään tai atomisesti.
Laitteiston ajurit integroidaan suoraan kerneliin joko käännön yhteydessä tai dynaamisesti insertoimalla.
Monoliittisessa kernelissä, kontekstinvaihdon yhteydessä, ei tarvitsekkaan käyttää prosessorin rekistereitä mihinkään muuhun kuin enintään system call:in numeron ja kenties sen parametrien välitykseen (esim. Linsuxin fastcall-menetelmässä). Kaikki pyydetyn palvelun operaatiot hoidetaan VIIPYMÄTTÄ kernelissä sisäisesti, ja tungetaan system callin paluuarvo kutsuneen prosessin pinoon (ainakin jos käytetään system callin toteutuksessa perinteistä C-funktiokutsun tyyliä).
Mikrokernelissä taasen palvelun hoitaa useimmiten joku muu prosessi. Itse kernel toimii ainoastaan palvelupyynnön, eli IPC kutsun, välittäjänä. Tällöin on ERITYISEN TÄRKEÄÄ, että prosessorissa on paljon rekistereitä, jotta kaikki palvelupyynnön parametrit voitaisiin välittää serverille ILMAN että kerneli joutuu välissä hitaasti kopioimaan dataa prosessilta toiselle.
Rekisterejä tarvitaan myös IPC kutsun endpointin, eli serverin, määrittelemiseen. Toisaalta pitää myös ilmoittaa monia muitakin IPC-tapahtumakohtaisia tietoja (kutsuvan prosessin id tms), jotka voivat viedä melkein kaikki yleiskäyttöiset rekisterit.
Itse IPC kutsun parametreille ei jää välttämättä tilaa.
Mach mikrokernelissähän tätä rekisterien vähäistä määrää IPC kutsun yhteydessä on pyritty kompensoimaan mappaamalla clientin ja serverin kesken yhteisiä muistisivuja, mutta ohjelmoinnin kannalta homma menee aika monimutkaiseksi ... ei-PIC käännetyn koodin ajaminen vaatii IPC kutsun yhteydessä välitettyjen pointtereiden jälkikäsittelyä kernelin taholta jne ... hemmetin monimutkaista.
Silti, vaikka IPC kutsun parametrit välitettäisiin yhteiseksi mapatun muistisivun kautta, pitää silti kutsuvan prosessin odottaa että ko. serveri skeduloidaan, ja että se tarkistaa tulleet palvelupyynnöt (ja kenties vastaa). KAMALA OVERHEADI! Mikrokernelien perisynti.
Mutta miettikäämme prosessoria missä on vaikkapa 32 rekisteriä. Periaatteessa KAIKKIEN järkevästi toteutettujen aikakriittisten IPC kutsujen parametrit voitaisiin välittää prosessilta toisiselle suoraan prosessorin välityksellä. Serverin skedulointia ei tarvitsisi odotella, vaan kerneli ajaisi serverissä kutsun käsittelevän funktion säikeenä, ja välittäisi parametrit sille suoraan rekisterien avulla. Samalla tavalla säie
tökkäisi paluuarvon (tai paluuarvot) rekistereihin, ja pyytäisi kerneliä skeduloimaan kutsuneen prosessin IPC kutsujen käsittelysäikeen.
Tämä on MINUN ja muutaman muunkin kaverini mielipide siitä miten unelmatilanteessa homma toimisi. ia32 prossuilla tämä vaatii aika paljon kikkailua. Mm. L4 mikrokernelillä IPC kutsun yhteydessä jää kolme (3) rekisteriä parametreille vapaaksi, ja se ei ole paljon. Siksi L4 tekeekin aika maagisia kikkailuja clientin ja serverin stackilla ...
Mutta kuitenkin, microkernelien IPC:hen pohjautuvalle toiminnalle on erittäin tärkeää että rekistereitä on käytettävissä paljon. Rekistereitä ei tarvitse ainoastaan kernelin IPC funktiot, vaan myös IPC kutsulla välitettävät parametrit.
Ja turha yrittää iskeä minua tuolla vanhalla "et tiedä mistä puhut". Olen tarpeeksi lukenut/kokeillut ja seurannut tätä monoliittisten ja mikrokernelien välillä käytävää kikkelinkasvatus skenesotaa, että tiedä about suunnillen mistä puhun ;)
BTW. Se, että joku prosessori muuntaa CISC käskyt sisäisesti RISC käskyiksi ei liity tähän asiaan mitenkään.
On se niin perseestä kun pitää kaikki mielipiteensä selittää niin perinjuurin ... huoh.
> Monoliittisissa kerneleissä itse kerneli tarjoaa
> KAIKKI laitteiston palvelut ohjelmille suoraan.
Niin tai sovellukset käyttävät esim. POSIX APIa ja
tekevät syysteemikutsuja laitteistolle, jonka
palvelee ko. laitteen ajuri.
> tungetaan system callin paluuarvo kutsuneen
> prosessin pinoon(ainakin jos käytetään system
> callin toteutuksessa perinteistä
> C-funktiokutsun tyyliä).
Tosin C konventiossa paluuarvo on x86-alustalla
eax-rekisteri.
> Mikrokernelissä taasen palvelun hoitaa
> useimmiten joku muu
> prosessi. Itse kernel toimii ainoastaan
> palvelupyynnön, eli IPC kutsun,
> välittäjänä. Tällöin on ERITYISEN TÄRKEÄÄ, että
> prosessorissa on paljon
> rekistereitä, jotta kaikki palvelupyynnön
> parametrit voitaisiin välittää
> serverille ILMAN että kerneli joutuu välissä
> hitaasti kopioimaan dataa
> prosessilta toiselle.
Tuohan jopa kuulostaa järkevältä. Ainoastaan
kiinnostaisi tietää, miten tuo on toteutettu
jossakin mikrokernelissä?
> Mach mikrokernelissähän tätä rekisterien
> vähäistä määrää IPC kutsun
> yhteydessä on pyritty kompensoimaan mappaamalla
> clientin ja serverin
> kesken yhteisiä muistisivuja, mutta ohjelmoinnin
> kannalta homma menee
> aika monimutkaiseksi
Niin kyseessähän on ihan yleinen COW (Copy On
Write), jota kyllä käytetään varmastikin kaikissa
moderneissa käyttöjärjestelmissä. Miten
se menee ohjelmoinnin kannalta monimutkaisemmaksi
kuin esim. se, että yritetään säilyttää
IPC-viestin parametreja ja paluuarvoja (joita siis
voi olla n-kappaletta) CPU:n rekistereissä (joita
siis yleensä < n kappaletta)?
Tuossahan riittää kun jättää muisti-sivun
kopioimatta niin kauan kun siihen ei kirjoiteta.
> Mutta miettikäämme prosessoria missä on vaikkapa
> 32 rekisteriä. Periaatteessa KAIKKIEN
> järkevästi toteutettujen
> aikakriittisten IPC kutsujen parametrit
> voitaisiin välittää prosessilta
> toisiselle suoraan prosessorin välityksellä.
> Serverin skedulointia ei
> tarvitsisi odotella, vaan kerneli ajaisi
> serverissä kutsun käsittelevän
> funktion säikeenä, ja välittäisi parametrit
> sille suoraan rekisterien
> avulla. Samalla tavalla säie tökkäisi paluuarvon
> (tai paluuarvot)
> rekistereihin, ja pyytäisi kerneliä skeduloimaan
> kutsuneen prosessin
> IPC kutsujen käsittelysäikeen.
Kerroppas nyt hieman tarkemmin. Eli IPC-kutsun
parametrit jätetään rekistereihin ja kerneli ei skeduloikaan serveriä vaan suorittaa kutsun
käsittelevän funktion säikeenä (== mitä helvettiä
toi tarkoittaa?) Jos tarkoitat, että nuo palvelut
ajetaan kernelissä säikeenä niin juuri noin asiat
nimenomaan yleensä tehdään. Prosessithan esim.
Solariksessa ja FreeBSD:ssä koostuvat säikeistä ja
niitä skeduloidaan. Jos siis ymmärsin oikein
(luultavasti en) niin väität, että säästytään
serverin skeduloinnilta skeduloimalla kernelin säie, joka nuo asiat tekee?
> [...] Siksi L4 tekeekin aika maagisia kikkailuja clientin ja serverin stackilla ...
Mitähän ne kikkailut sitten ovat? Ja jos voisit
vielä pistää jonkun autenttisen lähteen tällä
kertaa mukaan niin muutkin palstan lukijat
voisivat myös osallistua keskusteluun.
> Ja turha yrittää iskeä minua tuolla vanhalla "et
> tiedä mistä puhut". Olen
> tarpeeksi lukenut/kokeillut ja seurannut tätä
> monoliittisten ja
> mikrokernelien välillä käytävää kikkelinkasvatus
> skenesotaa, että tiedä
> about suunnillen mistä puhun ;)
No todennäköisesti keksit sanan "monoliittinen"
keskustelusta:
http://keskustelu.suomi24.fi/show.fcgi?category=108&conference=4500000000000141&posting=22000000012604692
, jossa väitit, että Solaris on mikrokerneli ;)
Ei nyt ehkä aivan sitä mitä haetaan, mutta mikrokerneli ja user-mode ajurit:
www.minix3.org
Mielenkiintoinen systeemi kaikille joita käyttöjärjestelmän syvällisempi toiminta kiinnostaa. Suunniteltu opetuskäyttöön.
> tungetaan system callin paluuarvo kutsuneen
> prosessin pinoon(ainakin jos käytetään system
> callin toteutuksessa perinteistä
> C-funktiokutsun tyyliä).
Jeps. Tuossa meni puurot ja vellit sekaisin. X86 kontekstissa kyseessä onkin tosiaan eax, kiitos kun korjasit.
Vittu en ees musita millon viimeksi nukuin.
Mutta eniweis ... asiaan
> Jos siis ymmärsin oikein
> (luultavasti en) niin väität, että säästytään
> serverin skeduloinnilta skeduloimalla kernelin
> säie, joka nuo asiat tekee?
Ei ihan.
Siis serveri kyllä skeduloidaan, mutta se tehdään viipymättä. Eli siis jos ko. IPC kutsun tekijä vaatii tiukkoja vasteaikoja, ajastetaan serveri heti kutsuneen prosessin jälkeen. Rekisteriin syötetyt parametrit säilyvät kontekstinvaihdon yli.
Kerneli luo IPC-kutsun käsittelevästä funktiosta serveriprosessin paikallisen säikeen, vaihtaa ring_3 ja suorittaa sen. Säie lukee parametrit rekisteristä ja tekee parametrien vaatimat temput.
Kun sitten operaatio on suoritettu, laittaa serveriprosessi paluuarvon/paluuarvot rekistereihin, ja pyytää kerneliä taasen ajastamaan kutsuneen asiakasprosessin.
Tietenkin tätä menetelmää tuskin käytetään realtime systeemeissä, mutta tuollainen rekistereillä kikkaileminen voisi auttaa overheadin vähentämisessä.
Ideana olisi siis, tiukkoja vasteaikoja vaativien asiakkaiden tapauksessa, ajastaa serverin säie viipymättä IPC-kutsun jälkeen, ja säikeen lopettaessa ajastaa kutsunut prosessi (ja sen IPC-kutsun käsittelijä säie) jälleen viipymättä.
Koska IPC-tapahtuman tärkeimmät parametrit kulkisivat rekistereissä (jotai siis olisi biljoona kpl), ei tarvitsisi mapata muistialueita IPC-kutsujen parametrien välitystä varten. Säästyy useita kellojaksoja, vai kuinka?
Tietenkään meillä ei x86:ssa ole biljoonia rekistereitä. Eli se siitä vai, olen pelkkä turhaan toivoon hukkunut unelmoija? ;)
>> , jossa väitit, että Solaris on mikrokerneli ;)
No niin väitin. Entä sitten?
Olen tietokoneharrastajien kanssa keskustellessani saanut sellaisen kuvan, että Solariksessa on hyvin paljon mikrokernelin piirteitä ytimessä.
Tästä sain siis idean, että se on mikrokerneli. Mutta ei tästä enempää. Jos se on sinun mielestä täysin monoliittinen köntti niin olkoon.
Jos prosessi tekee IPC-kutsun normaalilla prioriteetillä, niin tietenkin silloin kaikki kutsun parametrit säilötään kerneliin väliaikaisesti, kunnes on serverin vuoro tulla ajastetuksi.
Hmm.
Jos keksitte jotain pahoja puutteita tuossa minun ideassa niin kertokaa toki.
Ehkei helvetin suuri rekisterien määrä välttämättä tarkoita, että se masiina sen nopeampi olisi.
Mutta ohjelmointiteknisesti on aina sitä parempi, mitä enemmän niitä rekisterejä on ;)
User-space säikeet on totaalisen eri asia. Kerneli
ei edes tiedä noiden olemassaoloa. Kannattaa muuten katsella mielenkiintoinen toteutus:
http://www.gnu.org/software/pth/
Siellä on dokumentti, jossa selitetään miten
säikeille on luotu oma pino käyttämällä signaalin käsittelijän pinoa :)
> Siis serveri kyllä skeduloidaan, mutta se
> tehdään viipymättä. Eli siis jos ko.
> IPC kutsun tekijä vaatii tiukkoja vasteaikoja,
> ajastetaan serveri heti kutsuneen prosessin
> jälkeen. Rekisteriin syötetyt parametrit
> säilyvät kontekstinvaihdon yli.
Vastaavanlainen toiminnallisuus löytyy noin kaikista oikeista real-time käyttiksistä. Kutsutaan nimellä skedulointi prioriteetit.
Lisäksi kontekstin vaihdossa prosessin (säikeen) rekisterit normaalisti tallennetaan muistiin (mukaan lukien eip (x86)) eli jos rekisterit säilyvät niin mistä kohtaa esim. serveriprosessin suoritus alkaa?
Ja mitä tapahtuu jos järjestelmässä olisikin enemmän kuin kaksi prosessia?
No jokatapauksessa aika kulunut aihe, ehkä parempi aloittaa uusi topikki, josta sitten voi vääntää kättä :) Hauska enivei väitellä.
Ei vaan jaksanu enää alkaa tappeleen aiheesta "Windows vs Linux", joten vedin mukaan Mikrokernel vs Monoliittinen kernel ja vielä CISC vs RISC =D
Joo olen hieman kiero paskiainen, mutta ainakin sain jotain tekemistä. Rahat loppu, ja sitämyöten loppu kaljat, jotain tekemistä oltava ;)
> Lisäksi kontekstin vaihdossa prosessin (säikeen)
> rekisterit normaalisti tallennetaan muistiin
> (mukaan lukien eip (x86)) eli jos rekisterit
> säilyvät niin mistä kohtaa esim.
> serveriprosessin suoritus alkaa?
Normaalisti näin tehdäänkin. Mutta mikään ei pakota tallentamaan ko. rekistereitä muistiin, jos niiden avulla on tarkoitus siirtää parametreja kutsutulle serverille.
L4 esim välittää 3 32-bittistä parametria rekistereillä, loput sovellukset voi sitten siirtää vaikka mappaamalla muistisivun.
> Ja mitä tapahtuu jos järjestelmässä olisikin
> enemmän kuin kaksi prosessia?
Hmm, en nyt muista miten L4:ssa oli ko. ongelma ratkaistu. Ehkä threadien hallinta kernel-tasolla mahdollistaisi semmosen kontrollin, että threadin luomisvaiheessa ei uusia ajastuksia oteta vastaan tms. En ole varma, en ole miettinyt vielä näin pitkälle ;)
Mutta joo aika vanha aihe.
> http://www.gnu.org/software/pth/
> Siellä on dokumentti, jossa selitetään miten
> säikeille on luotu oma pino käyttämällä
> signaalin käsittelijän pinoa :)
Aivan hieno thread toteutus. Ainoa haitta on, että se on perkeleen syöpä-GPL:llä. Mutta mikään tuskin estää minua ottamasta mallia ... hmm
Mutta ottihan Sony BMG:kin VLC Playeristä lähdekoodia ... :D:D
Línuxin kerneli ei ole mikään monoliittinen, se mitä otat mukaan kerneliin riippuu täysin itsestäsi. Toimiva käyttövalmis Linux ympäristö voidaan puristaa mahtumaan kokonaisuudessaan yhdelle USB muistitikulle tai jopa parille korpulle.
Linuxissa nimenomaan käyttäjä voi vaikuttaa siihen mitä kerneliin käännetään mukaan ja mitä ei. Tarpeen mukaan siihen voidaan ottaa mukaan paljon tavaraa, tai kernelistä voidaan tehdä hyvin pieni.
Joten toi sunvuodatuksesi oli täyttä roskaa, ja osotus siitä että olet ihan pihalla.
Dynaamisesti ladattavat moduulit eivät tee kernelistä mikrokerneliä.
Atomisesti tai kernel threadeina ne kaikki ohjelmien järjestelmältä vaatimat palvelut siellä kernel spacessa kuitenkin toteutetaan. Ei ole mitään merkitystä, onko noi operaatiot määrittelevä koodi käännetty kerneliin staattisesti, vai linkitetty binäärimokkulasta ajon aikana.
Jos sovellusten tarvitsemat palvelut toteutetaan omilla userspace servereillä, jotka palvelevat kernel välittäjänään asiakasprosesseja, niin silloin on kyseessä mikrokernel.
Selkeä ero. Olettaisin.
lue: http://fi.wikipedia.org/wiki/Kernel
Suosittelen myös muille asiasta kiinnostuneille/tietämättömille.
....uudelleen avatuksi!
Töissä on kyllä kivasti nurinpäin tuo kehitys.
Ennen vakaat PC:t on alkaneet kaatuilla ihan itsekseen mitä ihmeellisimpiin virheilmoituksiin yms. Kaikessa koetetaan päästä irti Windows kytkystä.
Linuxista:
- onhan se kamalan iso ja raskassoutuinen mutta on se tajuttoman paljon Windowsia stabiilinpi ja kehittyneempi, esimerkiksi juuri nuissa päivitysasioissa
>Windows (mikrokerneli)
Mikrokernelin irvikuva!
Esim QNX on sellainen käyttis josta kannattaa ottaa mikrokernelin mallia. Jopa kernelin pystyy vaihtamaan ilman alasajoa! ja tietenkin kaatuvat ajurit potkitaan uudestaan käyntiin ilman resettiä.
>- Kerneli sisältää vain tärkeimmät ja on siten erittäin minimalistinen ja siten se on erittäin nopea, kevyt ja vakaa käytössä.
Se on valtava. Joskaan ei niin valtava kuin Linuxissa, käsittääkseni. Kun windowsia käyttää niin kernelin hukkaama CPU aika on puhutteleva. Esim sovellusten prioriteeteilla ei ole mitään merkitystä kun kerneli jumittaa toiminnat.
>- Ajurit eivät ole sisälletetty kerneliin, joten virhe ajurin koodissa kaataa ainoastaan ajurin, ei koko käyttöjärjestelmää. Sama ohjelmissa. Ohjelman virheellinen toiminta kaataa ainoastaan ohjelman, ei koko järjestelmää.
No mikä sitä windowsia sitten kaataa jatkuvasti ja Linux senkun pelittää?
>- Käyttöjärjestelmään tulevat päivitykset eivät yleensä tarkoita uudelleenkäynnistystä ellei päivitys tule itse kerneliin, jolloin uudelleenkäynnistys on aina pakollinen.
Joka viikko tulee yhdestä kahteen reboottia, keskimäärin, tietoturvan vuoksi.
Lisäksi joka tapauksessa kerran viikossa pitää resetoida, muutoin windows alkaa häröilemään eikä pysty enään ajamaan kuin yhtä sovellusta kerrallaan.
>Uusi windows tosin tulee korjaamaan tämänkin, joten käytännössä se tarkoittaa entistä pitempiä uptime-tilastoja.
AInahan se windows on tullut hitaammaksi ja bugisemmaksi. Heillähän on se politiikka että featuret myy, ei korjaukset.
Windows on vähän kuin nokian puhelin. Pitäisi saada puhelut toimimaan luotettavasti ja alkaa sitten vasta säätää ominaisuuksilla.
"Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect."
- Linus Torvals, 2003
Lähde: After the SoftwareWars by Keith Curtis, sivu 16:
http://www.lulu.com/content/4964815
(Katso myös sivu 23... ;)