Já teda o tom právě po přečtení tohohle dílu přesvědčen nejsem. Je to napsané stylem, jako když student mlží u zkoušky. Navíc – jak už tu poznamenali jiní – některé pasáže jsou přímo zavádějící:
„Můžeme jim říkat popisovače tabulek“ – jakých tabulek? Snad tabulky popisovačů, ne? Vlastně celé to souvětí je jakési pomatené.
Zmínka o stránkování a segmentaci je příliš zjednodušená i na pouhý laický popis, natož na článek údajně pojednávající o psaní OS.
„Stránkování se také využívá pro účel virtuální paměti“ – cože? Stránkování je mechanismus, kterým se virtuální paměť realizuje! To je jako říct, že motor v autě slouží k vytápění a také se využívá pro účel pohonu vozidla.
„Proměnná gran je velikosti 1 bajt a představuje masku k nastavení granularity. Slouží tedy k nastavení několika klíčových parametrů segmentu, podobně jako proměnná attrib“ – a které nejsou ty klíčové? Nehledě k tomu, že čtenář z článku nezjistí, co to ta granularita vlastně je.
„Vidíme před sebou jeden záznam, který tvoří onu GDT – my jich budeme potřebovat 5“ – a proč? To by snad stálo za nějaký komentář, ne? Kromě toho, že jeden je nulový a další jsou datové a kódové pro R 0 a 3.
„Teď nastala otázka, jak oznámit procesoru, aby naši GDT použil – naštěstí existuje instrukce lgdt“ – to ale máme štěstí! No představte si, kdybychom takové štěstí neměli a instrukce lgdt by nějakou shodou náhod neexistovala – to bychom měli po žížalkách.
„Občas se nám může hodit tzv. přerušení, ať už vnější nebo vnitřní – to si lze představit jako nečekaný impuls procesoru, který říká, že se něco stalo. Máte např. uživatelský program, ve kterém nemůžete přistupovat na adresy jako 0×b0000, apod. ale máte za cíl vypsat text na obrazovce. Jak to tedy udělat ? Použijeme přerušení :) – jeho instrukce se jmenuje int a jako parametr se používá hodnota, která označuje jeho druh.“ – to jako autor myslí vážně? S prominutím – byl střízliv a plně při smyslech, když tuto nesmyslnost psal?
„usmyslíme si, že přerušení s ID 0×80 bude vypisovat znak, který předáme pomocí registru, může ho náš program směle zavolat“ – autor čtenářům dokonale zamlžuje (nebo si to sám plete?) rozdíl mezi hardwarovým a softwarovým přerušením. Začne psát o hardwarové žádosti o přerušení (IRQ) a pak, bez jakéhokoliv varování, pokračuje (hodně zjednodušeným) popisem mechanismu softwarových přerušení (nebo-li programových výjimek). Přitom se jedná o dost odlišné věci – jedno je asynchronní, druhé je synchronní, na neinteláckých procesorech se to často vůbec neimplementuje (není to nezbytné), nebo se tomu (jak je vidět, tak docela prozíravě) raději říká úplně jinak – viz třeba instrukce TRAP na 68K.
„Každý záznam v tabulce zaregistruje funkci, která se vykoná, když se zavolá konkrétní přerušení.“ – „zavolá“? To asi nebude nejvhodnější slovo. Snad „…když dojde k přerušení“, ne?
„důležitý general protection fault (GPF), který nám říká, že došlo v paměti k chybě.“ – opravdu? Jako že třeba při čtení nesouhlasí parita dat kvůli nějakému rušení na sběrnici?
„Dnes jsme si tedy vytvořili užitečnou ochranu našeho jádra proti poškození paměti či dalším nežádaným vlivům.“ – tak to asi ještě ne. Zatím jen víme, jak eventuálně na to. ;-)
Měl byste vzít na vědomí, že kdybych začal rozepisovat každou věc, mohl bych psát jen o zmiňované granularitě jeden celý díl – snažím se vše trochu zjednodušit, což znamená, že pro úplné pochopení budete muset nastudovat dokumentaci. Co se týče přerušení, chtěl jsem jen podotknout, že něco takového vůbec existuje. Osobně se mi zdá, že se moc vrtáte ve slovech, vím že nejsem žádný spisovatel a právě proto jsem odkázal i na tu dokumentaci – jestli si chcete napsat vlastní systém a rozumět mu, není moc jiných cest. Snažím se to psát pro normální lidi (čím více termínů, tím hůř) – mimochodem taky pracujete na operačním systému ?
Měl byste vzít na vědomí, že kdybych začal rozepisovat každou věc, mohl bych psát jen o zmiňované granularitě jeden celý díl – snažím se vše trochu zjednodušit, což znamená, že pro úplné pochopení budete muset nastudovat dokumentaci.
Právě že by to mělo být obráceně – ne sem fouknout strukturu GDT bez toho abyste čtenáři vysvětlil k čemu to vlastně je dobré, ale naopak byste měl nejdřív vysvětlit k čemu a jak procesor GDT a IDT používá a pro detailní strukturu odkázat na dokumentaci.
Tenhle díl fakt nemá hlavu, patu a ani smysl. Kdo tyhle věci předem neznal je z článku určitě nepochopil a kdo to znal teď oprávněně prská že to místy nedává smysl. Jestli to píšete pro začátečníky tak holt musíte vysvětlit základy – stránkování a segmentování by určitě vydalo na samostatný článek ale bylo by to dobře vynaložené úsilí protože bez jejich pochopení se nedá vysvětlit třeba virtuální paměť. Odbýt stránkování a segmentování jedním odstavcem a pak se bez dalšího vysvětlování vrhnout na technické detaily nastavování GDT je fakt trochu mimo mísu.
To je právě IMHO špatně. Bez pořádného vysvětlení jak v chráněném režimu funguje paměť a adresování nemá smysl se zabývat GDT. Je to trochu jiné než v prvním díle při ovládání VGA – každý asi tuší k čemu může být psaní na obrazovku dobré takže není potřeba moc okecávat _proč_ to děláme a je celkem ok hned ukázat kód. Jenže o GDT a IDT určitě naprostá většina čtenářů vůbec netuší k čemu by jim to mělo být dobré a z článku se do nedozví, takže ukazovat jim jak se to nastavuje je k ničemu.
Dejme tomu že se dostanete k nějakým domorodcům v pralese kteří v životě neviděli auto. Když jim ukážete že to jezdí dopředu a dá se točit volantem tak to asi pochopí. Ale bez toho abyste jim ukázal že tam někde je schovnej motor a vysvětlil jim jak to celé funguje nemá cenu je učit jak se v něm vyměňují svíčky.
Stejně tak tady nemá cenu mluvit o lgdt instrukci když většina čtenářů v té chvíli nemá tušení čeho vlastně mají docílit.
O zmíněné granularitě by stačil jeden odstavec, ale stránkování si (minimálně) jeden celý díl určitě zaslouží, stejně tak problematika přerušení. Věřím, že se k tomu určitě ještě hodláte vrátit, ale v tom případě stačilo napsat, že si nastavíme některé tabulky, nad jejichž obsahem nebudeme momentálně meditovat a rozebereme si to v budoucnu. Nežli se pokoušet to popsat takhle lajdácky. ;-) Období vrtání se ve slovech mám už za sebou, pokouším se naopak být hodně shovívavý a chápavý, ale co je moc, to je fakt moc – odstavec o přerušeních je opravdu napsán stylem, jako byste začal popisovat pilník, od půlky věty byste najednou popisoval hoblík a celý popis byste motivoval příkladem, jak se dá hoblík použít k zatlučení šroubu. V příštím díle přeji přeci jen šťastnější ruku při výběru témat a jejich zpracování. ;-)
K poslední otázce – ano, vyvíjím; jednak je to má práce (v oblasti „embedded“), jednak je to můj koníček (ale jakožto člověk silně ovlivněný pracemi Ch. Moora, A. Kaye a N. Wirtha se zajímám hlavně o alternativní a experimentální směry).
No, taky mi dnešní článěk přišel jako slovní salát. Hlavně by autor měl zdůraznit, že GDT je přežitek z 286, nutná zbytečnost, kterou jednou nastavíš, pak zapomenš, že existuje a nikdy víc na ni nesaháš.
Takové věci, jako x86 segmentace, jsou přesně důsledkem toho stylu návrhu bez programování, co dole popisuje Filo – nekdo navrhne featuru, aniž by byl programátor a zkusil ji použít, druhý ji podle návrhu implementuje, třetí zjistí, že je to pro programování nepoužitelné, ale už je příliš pozdě ji měnit.
Mě se segmentace při psaní OS líbila, protože umí lépe nastavovat práva pro čtení/zápis/spuštění a ring určité části paměti než stránkování (kde jsou akorát NX, RW/RO bit a S/U bit), čímž může značně zvýšit ochranu mikrojaderného systému (pokud používá i ringy 1 a 2) proti chybám jako např. buffer overflow či poison null byte a mrzí mě, že v x86–64 už není.
To není dáno kvalitou segmentace, nýbrž blbou implementací stránkování (stačilo by do tabulky stránek přidat dva bity na práva pro ringy 0/1/2/3 a bylo by to bez segmentace).
Pokud chceš jeden kernel ring a dva userspace ringy, dá se to „bez segmentace“ udělat tak, že nastavíš userspacové segmenty pro oba ringy na bázi 0 a limit 3GB, pak si pomocí bitu U/S v tabulce stránek můžeš vybírat, ze kterého userspacového ringu je stránka přístupná (přičemž stránky v rozsahu 3–4GB budou pouze pro kernel). Jenže tím zase přijdeš o fast syscally: SYSCALL a SYSENTER. Když chceš plné 4 ringy, tak pak už s těmi segmenty manipulovat musíš.
Na co přesně jsi ty ringy použil?
Ano, s tím souhlasím, na druhou stranu ta segmentace umožnila na von Neumannově architektuře simulovat Harvardskou, které se mi tak nějak víc líbí, protože má oddělené instrukce a data. Ale jde spíš o zvyk.
Chtěl jsem to použít pro ovladače, které potřebují přístup k I/O (ring 1) a ovladače bez přístupu k I/O (ring 2) nastavením IOPL. Nakonec jsem to ale implementoval přes I/O Permission Bit Map v ringu 3.
Pokud ty ovladače dáme do jednoho adresního prostoru na ring 1 nebo 2, tak nám to žádnou ochranu nepřinese, sice tomu ringu 2 zabráníme sahat na I/O porty, ale jeden ovladač bude moct stejně zničit libovolný jiný ovladač běžící na témže ringu a znefunkčnit celý systém. Když ovladače dáme každý do zvláštního procesu, tak zas nepotřebujeme ringy, dá se to řešit bitmapou nebo IOPL pro jednotlivé procesy.
Ringy používá XEN (hypervisor/kernel/userspace). Taky to používalo VMS na to, aby v jednom procesu mohl běžet shell i program, a aby ten program nemohl zničit shell. Ale jinak moc použití nemají…
Kde autor bere přesvědčení, že int, short a char mají 32, 16 a 8 bitů? Seriál nesleduji, takže je možné, že někde na začátku je takové prohlášení nebo alespoň něco ve stylu GCC na i386. Jen mi přijde z hlediska výuky a taky přenositelnosti lepší použít typy, které svoje velikosti garantují. Zrovna v případě packed struktur to má významný význam. Navíc by odpadly komentáře typu 16b příznak, pokud se využívají všechny bity typu.
> z hlediska […] přenositelnosti
To jsem nějak nepochopil. Vždyť celá ta struktura má smysl jenom na i386, tak kam by to kdo chtěl přenášet? Jo, jako, že to může kompilovat GCC, ICC nebo MSVC? Ale vždyť tam všude je char 8 bitů, short 16 bitů a int i long 32 bitů…
Ale jo, asi měl použít assembler (ať už se syntaxí Intel nebo AT&T). Operační systém úplně bez assembleru beztak napsat nejde.
Ako tu uz bolo napisane tak kritika je asi fakt nepripustna ze. To ze to nema hlavu a petu este beriem ale tvrdit ze ochrana pametoveho priestoru je strankovanie ? A vobec porovnavat strankovanie sa segmentaciu to trochu ujete. A to uz ani nehovorim ze odbit ring 1 a 2 tym ze sa proste nepouzivaju a hotovo, zvlast v clanku ktory by mal byt aj trochu vyucny je sila. Keby sa ring 1 a 2 pouzivali na x86 tak tu nemusi AMD vymslat voloviny ako NX bit a podobne.Aspon by stalo za napisanie preco je to tak ze sa na x86 pouzvaju majoritne iba dva ringy.Na windows platforme sa to taha od WindowsNT ktore existovali aj pre alphu a ta mala len dva, a ostatne systemy (linux) pravdepodobne z toho isteho dovodu – vecsina riskovskych cpu ma len dva ringy, popripade vedia emulovat aj viacej, ale zaver je ten ze pre portabilny os je vyhodne pouzivat iba 2. Pritom by mohol byt zaujimavy navrh os kde kernel bezi v 0,ovladace v 1, podpisane app v 2 a ostatny bordel v 3 a hned by bolo bezpecnejsie.
Kdyz nastavite jedne strance atribut pro readonly a druhe pro zapis a jako uzivatelsky program zacnete zapisovat prave do te RO, program spadne a jadro zabrani neopravnenemu zasahu do pameti – copak tohle neni ochrana ? Prosim prectete si alespon cely clanek a abyste chapal vsechen text, doporucuji shlednout i ty predchozi. Toto je serial :)
Ano, jeto ochrana, ale velmi primitivní. Například to nezabrání tomu, aby jeden proces přepsal data druhého procesu. Vzhledem k tomu, že hned v další větě píšete „Obě metody ochrany paměti mají své výhody i nevýhody, stránkování je však užitečnější“, můžu snadno tvrdit že nemáte pravdu. Pomocí správně nastavené segmentace totiž můžu dosáhnout naprostého oddělení procesů (tak, že vůbec nemají přístup k jiným datům než svým vlastním), což stránkování neumožňuje. Naopak segmentu můžu nastavit, jestli má být jen pro čtení nebo pro zápis (nebo obojí).
Takže si dovoluji tvrdit, že ve srovnání se segmentací nepřináší stránkování žádnou ochranu paměti.
V praxi je možné, že budu oba mechanismy kombinovat (např. nějaký hradware má šikovně nastavenou paměť, takže registry pro čtení budou zabírat jednu stránku, a RW registry jinou). Pak uživatelský program například dostane velký RW segment, jehož některé části budou jen pro čtení. To ale není právě typický případ ochrany paměti (a je potřeba jej explicitně zmínit).
S tvrzením „Například to nezabrání tomu, aby jeden proces přepsal data druhého procesu.“ bohužel nemohu souhlasit. Každý proces totiž má vlastní soubor stránek a mezi jednotlivými soubory se při každé změně tasku procesu přepíná. To znamená, že každý proces má nastaveny mezi jinými i blok paměti pro zápis (jeho proces) a zbytek např. čtení, jakmile začne zapisovat určitý proces do paměti, která mu nepatří, měl by se proces ukončit. Jedině pokud bychom měli jen jeden soubor stránek pro všechny procesy stejný, pak by to fungovalo tak jak píšete.
skusim to povedat inak, je fajn ze sa niekto pusti do takejto nepochybne zaujimavej temy – OS. Ale neviem preco je v dnesnej dobe take modne pisat o niecom aspon zle ako vobec.Kritika je neprijemna ale to na veci nemeni ze koncept tohto serialu je znacne chaoticky a bud ma autor medzery (co neni myslene ako urazka ale ako fakt) alebo zle vybera to co napise a ako to napise.Proste zacat pisat o OS bez popisu hw architektury na ktorej ma bezat je dost nevhodne.
Nekteri bohuzel nepochopili tento koncept, beru vas nazor, ale neni mi jasne, proc bych mel popisovat strukturu hw, kdyz to uz udelalo spoustu jinych clanku, kdezto podobnych serialu v cestine hodne nenajdete. Myslim, ze daleko poucnejsi je postupne odkryvat jednotlive moznosti dane architektury a kombinovat to s praktickou ukazkou, nez hned ze zacatku vybalit spoustu, vetsine nic nerikajicich pojmu … Pokud se bavime vzdycky jen o konkretni casti, neudelame tim v hlave zmatek. Dulezite je, aby na konci ctenar vedel, ze se to nejak tak dela a mel k tomu bliz. Jak uz jsem psal minule, cilem neni napsat dokonaly OS a urcite nejsou me clanky bezchybne, ale nerekl bych, ze v tom nemam jasno, to by napr. Linus nezaradil kusy meho kodu do hlavni vetve linuxu :) Sice nejsem za kritiku rad, ale prijimam ji a snazim se podle toho i zachovat, bohuzel na nektere pripominky uz je pozde.
Podle mého tohle není programování. Snad kódování, ale ještě spíš jakási bastlírna udělátek.
Ke skutečnému programování OS – a vlastně čehokoli jiného – vůbec není zapotřebí počítač, přinejmenším ne v první fázi. Především je třeba si ujasnit cíle, oč se vlastně snažíme a proč, pak zvolit rámcově, bez velkých technických detailů realizační cesty, a pak až snad někde úplně v závěru to nějaký dobrák může převést do kódu – to už je to nejmenší.
Ten váš kód možná bude nakonec operační, systém to ale nebude docela určitě a to co provozujete bych programováním určitě nenazval. Ne v roce 2009.
Mohu se zeptat, kolik funkčních OS za sebou máte? Autor seriálu má minimálně 1 cvičný, který sice není určitě ve finální verzi, ale dovedu si představit, že i tak by se již dal k něčemu použít. Stačí se obtěžovat a zkusit. Je volně k dispozici. Je pravděpodobné, že jste typický žvanil teoretik, který umí sice básnit o tom jak by to mělo vypadat, ale ve skutečnosti má problémy do hloubky chápat jak vůbec funguje třeba procesor. Znám takové, učí někdy i na vysokých školách. Autorovi článku musím ale také vyčinit. Tento díl je opravdu zmatený – chtělo by to před zveřejněním dát článek někomu přečíst. Chápu úmysl napřed objasnit jak některé věci vespod fungují(čtenář má pak prostředí, kde může experimentovat s procesorem a hw než začne opravdu dělat OS), ale ůvodní nastínění cíle – třeba co vše má náš OS umět a jak toho dosáhnout – by určitě neškodilo.
Co se týče opravy gramatických chyb, apod., tak každý článek procházi přez korekturu, kde se změní některá slova, opraví příp. hrubky, popř. formátování – toto už ale na starosti nemám. Tento článek byl hotov už před více jak týdnem, ale z nějakého důvodu se spozdil, kdybych s tímto textem mohl mezitím manipulovat i po vložení do redakčního systému, určitě by to nepřišlo na škodu.
Když to bude navrhovat člověk, co to neprogramuje, tak to dopadne tak, že do návrhu dá věci, co jdou obtížně naprogramovat, věci, co nejsou potřeba, věci, co jsou vedou k bugovitosti nebo pomalosti apod.
Rozdělením práce na návrh, analýzu a kódování uděláš firemní informační systém, ale nic složitějšího ne.
Samozřejmě rozdělení projektu OS na návrh, analýzu a kódování má velmi dobrý důvod. Když se to neudělá, tak vznikne bastard typu prvních verzí Linuxu. Návrhy obecně bez ohledu na konkrétní projekt musí dělat někdo, kdo věci rozumí. V případě OS by to měl být senior developer se zkušeností v oboru. Příkladem budiž David Neil Cutler, designer zřejmě nejúspěšnějšího systému na světě (Windows NT). Jeho zkušenosti z RSX-11M, VMS a VAXELN byly dobře využity.
Věřím čemu? Že by se měl u OS provádět design s tužkou v ruce, a ne s editorem zdrojáku? Tomu samozřejmě věřím. Že David Cutler je příkladem člověka, který je schopen OS dobře navrhnout? Ano, tomu také věřím. Že Windows NT je zřejmě nejúspěšnější systém na světě? Můžeme o tom diskutovat, ale podle mě to tak je. Vezměte si množství instalací Windows desktopů a serverů. Jestli se s tím může měřit někdo jiný, rád se dozvím podrobnosti.
Možná narážíte na ty první verze Linuxu. Ty ale byly opravdu hrozné. Linus psal terminálový emulátor, a u toho občas přepsal nějaké API starých UNIXů podle jejich dokumentace. Nakonec spatlal monolitický kernel s podporou až 64 procesů a s hromadou kódu v ASM, nad jehož designem by slabší jedinci mohli zvracet. Teprve léta šlechtění (Linuse i Linuxu) vedly k zavedení portability, kernelových modulů, částečné preempce kernelu (PREEMPT_VOLUNTARY je tuším až v kernelu 2.6, PREEMPT je dodnes v produkci nepoužívaný a nepoužitelný), multithreadingu atd. Přitom stačilo na začátku navrhovat a plánovat, a nebylo by pak nutné řadu věcí přepisovat. Implementace preempce kernelu nebo multithreadingu je logicky daleko složitější, když se pro ní rozhodnete až po pár letech. I dnes by řada věcí na kernelu zasloužila přepsat, ale čím déle se to odkládá, tím víc to pak bolí.
Nevěříte? Méně věřte legendám, a více faktům. Přečtěte si třeba zde: Linus představuje Linux, srovnání Linuxu a FreeBSD tady na rootu. Podívejte se na historii preempce kernelu (PREEMPT_VOLUNTARY byla pěkná řezničina), nebo na multithreading (vycházel původně z volání clone()). Srovnání architektury Linuxu se Solarisem nebo NT vyznívá pro Linux dost mizerně. Ale vyprávějte to lidem, pro které je operační systém náboženstvím.
To, že se kód zahazuje a přepisuje, dělají všichni vývojáři, i Microsoft. Ještě před 10 lety dodával na desktopy Windows 98 a ME, které neměly ochranu paměti (a daly se shodit dvojicí instrukcí CLI;HLT). A ještě před 20 lety byl běžný DOS. A současné Windows DOSové a Win16 programy stále pouští, ale kód byl zcela přepsán.
A třeba první Apple uměl pustit jen jeden program, pak to začalo uživatelům vadit, tak udělali možnost pustit víc programů, stále jim vadilo, že si ty programy mohou lézt do paměti, tak přešli na OS X.
Ty nedostatky starých systémů nejsou dány blbostí návrhářů, ale tím, že tehdy byly na systémy jiné požadavky. Apple měl požadavek, že musí běžet ve 128kB RAM, tak víc programů ani ochranu neimplementovali. To, že se od té doby paměť stala levná a uživatelé začali chtít víc programů, za to původní návrháři nemohou a nejde jim to dávat za vinu. Stejně tak v době Windows nebyl potřeba preemptivní multitasking nebo ochrana aplikací, tak tam nebyl implementován. Stejně tak Linus v roce 91 řekl, že víc než 64 procesů, každý s 64MB, není potřeba, tak víc neimplementoval. Bylo by možno na tehdy dodávaných Windows 3.1 pustit 64 procesů a mohl tam proces alokovat 64MB? … ale ono to je jedno, protože tehdy to žádný uživatel nechtěl
Windows NT nejsou „zahozením a přepisem“ DOSu, ale prostě jiný koncept. A nedostatky původního Linuxu jsou zjevně dané právě tím, že žádný návrh neproběhl. Bohužel jako se DOS těžko dá inkrementálně přepsat na NT, podobně je těžké z Linuxu udělat lepší OS. A proto je třeba na začátku navrhovat kvalitně.
V roce 91 byly ve vývoji Windows NT (stejně jako Linux), a na rozdíl od Linuxu byly od začátku navržené daleko lépe.
V roce 91 byly ve vývoji Windows NT (stejně jako Linux), a na rozdíl od Linuxu byly od začátku navržené daleko lépe.
To je jasne, ze windows NT jsou lip udelane… to, ze jdou provozovat jenom na domacich pocitacich a servrech vypadajicich jako lepsi domaci pocitace byl zamer hlavniho architekta…
O nadrazenosti NT architektury vypovida i jeji masivni nasazeni v mobilnich telefonech i na pocitacich z top500!
… a na rozdíl od Linuxu na většině tehdejších počítačů nemohly běžet. Já jsem měl 486 s 4 a později 8MB RAM (až v roce 98 jsem koupil Pentium s 32MB). Na střední školy byly 386–486 s 1–4MB (pouze server měl 16MB a běžel na něm Novell). NT měly víc featur než tehdejší Linux, ale ty featury jsou člověku na nic, když NT mu na počítači neběží a Linux ano.
Windows 3.x měly úplně stejně vypadající GUI jako NT 3.x a potřebovaly 1MB na provoz. Takže GUI samotné za to nemůže.
Jen příklad, vezměme si ovladač, který nedělá nic jiného než pípne při příchodu požadavku: http://doxygen.reactos.org/…beep_8c.html – má 400 řádků, 9 funkcí a 1 bugu (schválně, kdo ji najde?) V DOSu by se taková věc dala napsat na 2 funkce, v Linux možná tak na 4 funkce. Je to příklad sice primitivní, ale je třeba si uvědomit, že když se navrhne příliš složité rozhraní, tak všechen jaderný kód takhle nabobtnává.
BTW. minimální požadavky na systémy pro provoz textového režimu bez GUI:
DOS – 512kB Linux-0.X – 2MB Linux-2.0.X – 4MB Linux-2.6.X – 12MB
– takže můžeme říkat, jak staré verze Linuxu jsou špatně udělané … jenomže v devadesátých letech měl málokdo v počítači 12MB.
Co se týče GUI jsou ty rozdíly ještě horší: Apple – 128kB Windows 3 – 1MB Windows 95 – 4–8MB Linux 2.0 + XFree 3.6 – 8MB Windows NT 3 a 4 – 12MB Windows XP – 64MB Windows Vista – 512MB Nějaké moderní Linuxové GUI – asi podobně jako Vista, podle množství grafických serepatiček.
– takže na otázku, co by bylo, kdyby návrháři před 20 lety vyvinuli moderní operační systém, je odpověď: Neběželo by to!
–
Na zvracení je mi někdy naopak ze současného kódu Linuxu, např. na probuzení procesu se volá 8 vnořených funkcí, z nichž 7 nedělá nic jiného než předává argumenty další funkci, až ta poslední ten proces slavnostně přidá do fronty. Holt v tom kódu někdo strašně obsesivně hledal společné kusy a refaktoroval ho — až hloubka volání najednou byla 8 (na Sparc64 každá funkce sežere minimálně 192 bytů na zásobníku, takže to přispělo k pádu přetečením zásobníku … navíc to zpomaluje, protože to zcela vyprázdní všechna registrová okna). Takovéhle věci ve starém Linuxu (2.0 a nižší) nebyly.
„HW náročnost nemá s vlastním kernelem moc společného.“
Má, pokud programátor má možnost udělat optimalizaci, která urychlí běh, ale sežere třeba 1MB RAM, tak dnes ji beze studu udělá, zatímco před 15 lety by to neudělal.
Třeba kernel Linuxu 2.6 sežere asi 8MB neswapovatelné paměti. Před 12 lety to bylo celkové množství paměti, co jsem v počítači měl. Takže na tom počítači by Linux 2.6 běžet nemohl.
„A celý OS se pak typicky staví tak náročný, aby slušně běžel na v té době prodávaném HW.“
Ano. Proto byl Linux 0.x a 1.x udělán tak jak byl.
Řeknu to jinak. HW náročnost OS není daná (jen) kernelem.
Samozřejmě dnes mají počítače GB paměti, a minimálně stovky GB diskového prostoru. Nemá smysl dnes psát SW pro HW, který tu byl před 12 lety.
Myslíte, že by například preemptivní kernel spotřeboval výrazně více zdrojů? Nebo že by lepší architektura driverů či lepší obsluha přerušení vyžadovala více zdrojů? Podle mě ne. Linux 0.x a 1.x vpyadal jak vypadal díky absenci designu a amatérismu Linuse.
No ano, je tak úspěšný že běží na necelém jednom procentu všech počítačů na planetě :-D Na těchhle naštěstí ne. Na RSX-11M tu mám asi padesát kilo manuálů, moc zajímavé čtení, myslím že si to měli v MS také trochu nastudovat.
Obchodní úspěch není známka kvality, a naopak – viz třeba Tucker.
Ano, RSX-11 měl jiné určení, takže z něj jeho tvůrce v NT asi moc nepoužil, ne? Nebo naopak MS chce desktopový NT cpát i tam, kam není určeno? Třeba řízení železáren… Ale možná že v první verzi Škody Felicie také byla nějaká embedded verze NT, ty totiž občas bez jakéhokoliv důvodu za jízdy chcíply, muselo se vypnout zapalování a po chvíli znovu nastartovat.
Mimochodem, VMS, ač o spoustu let mladší, bezpečnosti tehdejšího Unixu zdaleka nedosahovalo, tam se teda Cutler čím chubit nemá ;-)
Úspěch u zákazníků je známka toho, že produkt plní jejich potřeby. Naúspěch produktu (natož produktu dostupného zdarma) naopak svědčí o neplnění potřeb zákazníků. BTW jaký Tucker?
U designu nového OS se počítá praxe s jakýmkoliv návrhem OS, stejně jako zkušenosti s jeho psaním.
Windows Embedded ve Felicii nikdy nebyly. Naopak řídí spousty technologických procesů, energetické sítě, najdete je v bankomatech, pokladnách, tiskárnách atd. Na rozdíl od domácích počítačů nemají embedded Windows problémy s přetaktováním, neznačkovým HW, zmršenými drivery, a nejsou na nich nainstalované hromady crippleware a kradeného SW. Proto s nimi nejsou větší problémy.
Úspěch u zákazníků je známka toho, že produkt plní jejich potřeby. Naúspěch produktu (natož produktu dostupného zdarma) naopak svědčí o neplnění potřeb zákazníků.
uspech softwaru u zakaznika odpovida jeho kvalite, zhruba stejne jako vypovida prodejnost desek o kvalite hudby britney spears… je to hnus, ale lidi to chteji, protoze nic lepsiho neznaji…
Britney Spears plní potřeby zákazníků, takže je prostě dobrá. Češi zase chtějí Lunetik, Karla Gotta a duo Eva a Vašek. Takovou kulturu totiž lidé chtějí. A kdyby chtěli, tak si místo toho koupí (mnohdy levnější) klasickou hudbu, jazz, klasický rock, nebo cokoliv jiného. Ale většina jich prostě nechce. Takže jaká hudba je kvalitní? Ta, kterou lidé (typiky) nechtějí poslouchat? To asi těžko.
Vaše měřítka hodnot a způsoby hodnocení jsou opravdu podivné. Takže tedy vězte, že kvalitní je to, co odolává času, módě, čehož hodnota je trvalá nebo někdy i s časem rostoucí, zkrátka co nevyhasíná. Po jakémsi lunetiku (už v současnosti ani nevím, co to bylo) za 10 let ani pes neštěkne, Bach nebo Deep Purple se ale bude hrát pořád. Krabice supermarketů za 20 let (snad) budou postupně bourány, chrám sv. Barbory budou tisíce lidí obdivovat pořád. Vůbec není důležité, co je momentálně nakrátko na výsluní, aby to posléze zapadlo v prachu. Pro to máme jiný výraz – populární. Ale populární a kvalitní jsou dvě naprosto rozdílné věci.
Vy chodíte nakupovat do chrámu sv. Barbory? Asi ne. Jaký má tedy smysl srovnávat novodobé tržiště se středověkým chrámem?
Zkusím to vysvětlit znovu. Kvalita je schopností statku plnit potřeby. V tržním systému lidé vybírají statky podle toho, jak plní jejich potřeby. Pokud lidé něco kupují, tak to zjevně plní jejich potřeby. Cokoliv jiného je čistě subjektivním hodnocením, a tedy naprosto od věci.
Aha, takže podle vás – byt představuje kvalitnější bydlení než dům se zahradou, protože po něm sáhla většina obyvatel u nás; jídelna představuje kvalitnější způsob stravování, protože ji v poledne upřednostní většina občanů před restaurací; kalkulačka, co umí jen sčítat, odčítat, násobit a dělit je podle vás kvalitnější, protože si ji koupí více lidí, než tu vědeckou; Eva a Vašek jsou kvalitnější, než Kožená, protože prodají víc cédéček; náboženské představy o Vesmíru jsou kvalitnější, než ty fyzikální, protože jim věří více lidí…?
Jak by asi řekl profesor Hrbolek – „vaše představy o tom, co je kvalitní, zdají se býti poněkud svérázné.“
Shitney neplní potřeby zákazníků ale vydavatelů, ta vaše zdánlivá potřeba je jen iluze vytvořená reklamou. Lidé chtějí to, co mají ostatní, to je princip módy a komerce! Jako v tomhle pravidelně aktualizovaném vtipu:
Představte si, že společnost Cray se rozhodne vyrábět osobní počítače. Má šestnáct stodvacetiosmibitových procesorů s frekvencí 9 GHz, 256 GB operační paměti, 50 TB kapacity disku, rozlišení obrazovky 8192×8192, dá se kompletně ovládat hlasem, vejde se vám do kapsy a stojí 300 dolarů. Co bude první otázka, na kterou se počítačová veřejnost zeptá?
„Jaký je v tom Windows?“
To mi není úplně jasné. Zákazníci si mohou svobodně vybrat, jakou hudbu si koupí. Nekupují si Bacha ani Deep Purple, ale Britney, Karla Gotta a Evu s Vaškem. Ti zákazníci znají svoje potřeby, a proto si vybírají právě to, co kupují. Cokoliv jiného je jen subjektivní soud, do kterého promítáte vlastní kulturní preference (které se u mě také neshodují s mainstreamovými).
V tom případě se asi shodneme, že u Linuxu se to s tím návrhem nějak nepovedlo.
Odpověď na první otázku je ano, na druhou asi ano. To „asi“ proto, že pokud OS píše třeba stovka vývojářů, tak je šéfarchitekt osobou, která by je měla spíš koordinovat (a kód určitě uvidí). Pokud se vůbec dostane k vlastnímu psaní kódu, tak bude jeho příspěvek velmi malý. Nakonec když někdo navrhne výškovou budovu nebo loď, tak také nemusí osobně pokládat základy nebo svařovat profily.
Ani ty Windows NT nevznikly s tužkou v ruce. API se taky od doby Windows NT 3.1 několikrát měnilo a rozšiřovalo. To nejde dělat vývoj systému způsobem „teď si sednu, vymyslím jakou architekturu má operační systém mít, vymyslím rozhraní pro aplikace, napíšu to na papír, pak to dám programátorům napsat a budu mít skvělý operační systém“. Když takhle budeme postupovat, tak získáme něco jako Windows 1.0, Windows NT 3.1 nebo Linux 0.01.
Smozřejmě, že v těchto systémech byla spousta věcí zbytečných, neefektivních nebo úplně špatně, což je důsledek toho odděleného návrhu, o čemž jsem psal původně.
API Windows NT se nějak výrazně měnilo? O tom bych se rád dozvěděl více.
Samozřejmě návrh OS musí vycházet z nějakého obchodního zadání (někdo to zpravidla platí). Například je účelem napsat RTOS, mezi předpokládané aplikace patří to a ono. Na základě toho uděláte design, který počítá s možností rozšiřování konceptu do budoucna. Na základě toho designu napíšete první verzi toho RTOS, při troše smůly budete muset občas zpátky k „rýsovacímu prknu“. A je tu první verze. Další verze provádějí korekce a rozšíření designu, případně se produkt cílí na širší cílové skupiny, nebo se naopak specializuje. Pokud jste se nestrefil, můžete vždy něco předělat. Čím jste lepší profík, tím více se zřejmě přiblížíte cíli. MS se zprvidla velmi dobře strefí do potřeb zákazníků už na třetí iteraci (viz Windows, Windows NT, SQL Server, Outlook a další), což není špatné. Ovšem ve spoustě případů i tak velká firma tvrdě selhala. Viz třeba dlouholeté neúspěšné snahy o embedded verzi Windows 3.x, které vedly až k napsání (konečně úspěšných) Windows CE.
Nějvětší změna bylo předávání všech syscallů procesu spravujícímu Win32 subsystém, který je teprv provedl pomocí interního NT API. Tohle bylo neúnostné, protože s každým novým procesorem je syscall a context-switch pomalejší (relativně k rychlosti procesoru). Tak to v NT 4 částečně převedli do kernelu. Bohužel ne úplně, tak je tam ten proces CSRSS a local procedure call rozhraní pořád, ale většinu syscallů jde rovnou do kernelového ovladače WIN32K.SYS.
Toto je třeba úkaz, že s tužkou a papírem člověk nic pořádně nenavrhne, protože se do toho návrhu dostanou nesmyslné věci typu proces spravující Win32 syscally.
Velké procento funkcí Win32 API je řešeno tak, že zavoláte knihovnu kernel32.dll, která poté provede syscall. Není mi jasné, proč by to mělo být pomalejší při zvýšení počtu procesorů. Pro SMP škálování Windows NT je naopak zásadní fakt, že je kernel preemptivní a reentrantní (na rozdíl od Linuxu).
V NT4 došlo k přesunu GDI a window manageru do kernelu. V NT4 bylo oboje součástí CSRSS.EXE, tedy v user mode. Jenže takový design v principu vede k velkému množství syscallů. Pokud přesunete GDI do kernelu, tak provedete jeden syscall, a dál už vše běží na straně kernelu. Poměrně pěkně to popisuje linkovaný článek. A když jsme u toho, tak ke změně API u celé akce NEDOŠLO. Aplikace totiž linkují proti user mode knihovnám. Jestli je ta či ona věc interně implementovaná v user mode nebo kernel mode, to aplikace nepozná.
http://technet.microsoft.com/…c750820.aspx
Nemám na mysli SMP, mám na mysli, že Pentium 1 syscall udělalo asi na 120 tiků, Pentium 2 na 250 (INT) / 150 (SYSENTER), Pentium 4 na 900 (INT) / 450 (SYSENTER). V těch procesorech je čím dál víc mikrokódu a provádějí syscally čím dál pomelaji.
Umístění toho Win32 subsystému do procesu je na nic. Vede to ke zpomalování (víc syscallů a navíc context switche) a nepřináší to žádnou hodnotu navíc: nezvýší to stabilitu (zkuste si ten proces CSRSS odstřelit – vytuhnou stejně celá Windows) a nezvýší to bezpečnost (když jeden uživatel vnutí CSRSS, aby vykonal jeho vlastní kód, tak má kontrolu nad celým systémem).
Mít speciální proces na Win32 subsystém by mělo smysl jen kdyby ten proces běžel na každého uživatele zvlášť. Pak by to sice bylo stále pomalé, ale přinášelo by to výhody: spadnutí Win32 procesu shodilo jen procesy daného uživatele a nechalo ostatní uživetele netknuté a kompromitování bezpečnosti Win32 procesu by opět vedlo jen k možnosti útočit na procesy toho samého uživatele, čili by to bezpečnost nijak neohrozilo.
Ale tak, jak to tam je, že máme jeden CSRSS proces pro všechny, to nemá smysl, to je jen výplod někoho, kdo na papír kreslil obdélníčky a šipečky. Což si vývojáři NT taky uvědomili a proto většinu funkcí toho procesu přesunuli do kernelu.
Jenže frekvence CPU se od dob Pentia (max 233MHz) výrazně zvýšily, takže jsou syscally daleko rychlejší. Samotné zvýšení počtu taktů na instrukci souvisí jednak s mikrokódem, ale také se zvýšením délky pipeline CPU (5 stages u Pentia, 10–16 u pozdějších CPU). Rozdělení pipeline CPU na více stages je výhodné pro částečnou paralelizaci provádění instrukcí, i když zvyšuje počet taktů na instrukci.
CSRSS obsahuje pouze user-space komponenty Win32 subsystému (třeba user-mode podporu textové konzole). Velká spousta funkcí Win32 se provádí v user space knihovnách (kernel32.dll, gdi32.dll, user32.dll, shell32.dll), které poté přímo provádějí syscally. Před NT 4.0 byly v CSRSS další funkce, o kterých se soudilo, že nejsou výkonově kritické. Ono dát například technologicky poměrně složité GDI32 do kernelu vyžaduje dost odladěný kód, aby kernel nebyl z hlediska bezpečnosti děravý jako řešeto. U NT 4.0 bylo GDI už dobře vyladěné, takže mohlo být přesunuto do kernelu. Stabilita a bezpečnost přesunutého kódu se ukázala jako dobrá, nakonec NT 4.0 najdete v některých firmách ještě dodnes.
Doporucuji si k tomu neco nastudovat. Spouste staromilcu se XP nelibi, ale (nejen) podle mne potencial ma. Zacit muzete treba zde: www.extremeprogramming.org
Obě odpovědi najdete v „AMD64 Architecture Programmer’s Manual – Volume 2: System Programming“ (http://support.amd.com/…cs/24593.pdf)
1) Kapitola 14 – Processor Initialization and Long Mode Activation
2) Kapitola 6.1 – Fast System Call and Return
– Přerušení 17 pushne na zásobník chybový kód. – U přerušení 1, 3, 4, 5 musíme povolit jejich volání z userspace (pokud je v userspace programech chceme používat) – t.j. dát jim atribut 0×EE místo 0×8E. – instrukce STI před IRET je zbytečná; IRET obnoví flagy, a tedy i flag povolení přerušení.
Tohle je ale ještě zmatenější… řekl bych to asi takhle:
1. Každý přístup do paměti má (aplikací) specifikovaný segment a adresu
2. Některé instrukce pracující s pamětí ale určité segmenty implikují např. call adr je jakoby call cs:adr – cs je kódový segment)
3. Když uděláme segment tak velký, jako největší úsek paměti, který může program adresovat, a program na ty segmenty pokud možno nebude šahat, bude tenhle segment moct používat a myslet si, jako že používá přímo lineární paměťový prostor (který je stránkovaný, a řeší tu virtuální paměť atd., neplést s fyzickou pamětí)
Zdravim, chci především poděkovat autorovi za tento zajímavý seriál. Myslím, že největší chybou, kterou udělal na začátku seriálu, bylo, že se ho rozhodl publikovat jej na root.cz , kde si uživatelé naprosto neváží cizí práce a vystavují autory velmi nepřiměřené kritice, která si neklade za cíl zlepšení článku, ale pošlapat cizí práci za účelem zvýšení vlastního ega. Byla by velká škoda, kdyby s psaním seriálu přestal kvůli atmosféře na root.cz, raději by měl přejít na jiný server, kde si jeho prace budou vážit.