Vlákno názorů k článku Porovnání systémů Linux a FreeBSD od jan molic - Dekuji za zajimavy clanek. Nejsem odbornikem na jadro,...
-
Článek je starý, nové názory již nelze přidávat.
-
jan molic (neregistrovaný)
Dekuji za zajimavy clanek. Nejsem odbornikem na jadro, ale to jeste neznamena, ze se o nej nezajimam.
Ocenuji Vas vyklad, ktery je i pro laika srozumitelny, a zaroven neni psan jako dvoustrankove clanky typu "Co vsechno lze delat s pocitacovou mysi".
BTW: Mohl byste treba jen okrajove zminit vyhody/nevyhody casto diskutovaneho monolitickeho kernelu vs mikrokernelu (napr. situaci, kdy selze ovladac v jadre a slozi cely system (z vl. zkusenosti); ovladacu bude pribyvat, riziko se zvysuje). -
ondra (neregistrovaný)
taky se pripojim ke gratulacim za vyborny clanek.
ad Monoliticky kernel....
Obavam se, ze detaily a srovnavani Monilitickeho kernelu, mikrokernelu nebo treba i exokernelu a ja nevim co jeste ...kernelu, by vydalo na samostatny clanek ne-li serial. Ne ze by to nebylo zajimave, prave NAOPAK - kdyby se nasel nekdo kdo se v problematice orientuje a napsal o tom clanek bylo by to velmi zasluzne. -
Mikulas Patocka (neregistrovaný)
To mne pripomina, ze uzivatelsky manual k nasem projektu skutecne obsahoval navod, jak klikat mysi --- u obhajoby si na to dokonce nekdo stezoval :-)
Co se tyce diskuze monoliticky kernel vs. mikrokernel --- dnes je to uplne dead. Mikrokernely se nepouzivaji. Casto se o necem prohlasuje, ze je to mikrokernel, i kdyz neni (napr. prvni verze Windows NT, BeOS). -
Mikuláš Patočka (neregistrovaný)
Mac OS X není mikrokernel. Dokonce v něm ani standartní unixový kernel "neběží" nad Machem jako proces. Mac OS X je normální BSD kernel, s kernelem obsluhujícím unixové syscally a se všemi drivery v kernelspace, který má přidané možnosti meziprocesové komunikace z Machu. Někomu nestačily pipy, unix domain sockety s sysV IPC, a tak si vymyslel, že tam chce ještě komunikační primitiva z Machu. Podle mě je to zbytečný featurismus.
-
kmotr (neregistrovaný)
Dobre, dopustil jsem se nepresnosti. Neni to nanokernel, jak tedy nekdo uvedl (BSD spusteny jako proces), neni to mikrokernel, jak jsem uvedl ja, ale taky to neni monoliticky kernel jak tvrdis ty. Je to kombinace, ktere se tusim rika hybridni kernel, ve kterem je cast sluzeb implementovana pomoci serveru (I/O, sprava prostredku) a cast je v "monoliticke" prilinkovane casti (BSD ABI). Dusledkem jsou dva jevy: jsem schopen pridavat ovladace zarizeni, fs a jine veci za behu systemu a pocitac je porad rozumne rychly. Za druhe: z toho vznikl asi ten maglajz, co si nasel ve zdrojakach darwinu ;)
vice zde:
http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/Mach/chapter_6_section_1.html#//apple_ref/doc/uid/TP30000905-CH209-TPXREF101
http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/Architecture/index.html -
Mikuláš Patočka (neregistrovaný)
Jakou to má přesně možnost pouštět ovladače v userspace? Tu jejich IO-KIT jsem nezkoumal, moc se mi nelíbila a navíc je v C++. Běží ty ovladače IO-Kit v kernelu nebo v userspace?
Po zběžném prohlédnutí jsem získal pocit, že to běží v kernelu, nicméně přímo ten kus kódu, který by překládal BSD buffer strategy na IO-KIT volání jsem nenašel.
Filesystém mají určitě v kernelu, tam je úplně normální BSD VNODE rozhraní. -
kmotr (neregistrovaný)
Priznavam, jsem vinen! Je to nejake divne :-) Moduly se sice daji dynamicky nahravat (prikaz kextload jako su, restart, plug and play jako user), ale cele bezi v kernel space. Do user space exportujou pouze rozhrani k danemu zarizeni. Priklad: ke SCSI karte je pripojeny scanner, kernel poskytuje pouze zakladni komunikaci mezi zarizenim a userspacem, k tomu vyuziva jine moduly v ramci IOKitu, napr. ovladac SCSI karty. Uzivatelsky software pouze vyuziva exportovaneho rozhrani k implementaci vyssich funkci nad zarizenim. Zmatlo mne asi to nahravani za behu, neni nutne prekomplivavat jadro kvuli kazde blbiny. Ne ze by to neslo, ale zmeny v jadre ma na starosti typicky Apple.
Kernel extensions se doporucuje pouzivat pouze pokud je k tomu duvod, protoze bezi prave v kernel space. Prikladem muze byt prave vzorkovaci zarizeni pro audio nebo jiny sirokopasmovy zdroj dat, jak tady nekdo poznamenal.
C++ (omezena podmnozina) je pry pouzita pro znovupouziti stavajiciho kodu. Pro vyvoj noveho ovladace staci vzit predpripraveny vzor, nebo jiny dostupny ovladac, trochu jej pozmenit a novy ovladac je na svete.
Za filesystem se omlouvam dvojnasob, je to blbost, samozrejme je v rezii BSD rozhrani, je to i na tech obrazcich.
PS: ja asi nejsem ten pravy na disputaci o kernelech, ale fakt mi prislo, ze masox nepouziva monoliticke jadro, ale nejakou kombinaci obou, kde ta mikro prevazuje. Asi ne a asi je to dobre, bohate staci, ze se porad pouziva emulace x86 ABI. -
marian (neregistrovaný)
Ano, cely Mac OS X je mierne schyzofrenny system (vacsinu zdedil z NextStep a do toho sa snazili "zadrotovat" nieco zo stareho Mac OS, preto je systemova arcitektura dost zlozita), ale s podivom im to, az na male problemy, cele funguje. Predpokladam ze tie komunikacne primitiva z Machu s vyhodou vyuziju ovladace zariadeni vyzadujuce RT riadenie (napr. karty na spracovanie zvuku, ci obrazu, co je na tejto platforme bezne), takze IMHO by som tieto vlastnosti napovazoval za nepouzitelne.
-
dejf (neregistrovaný)
QNX zije, na get.qnx.com je mozne si stahnout iso image tohohle systemu, nicmene je skoda ze jejich demodisky na diskete, ktere pripominaly z dnesni doby treba menuetOS, uz nejsou na hlavni site k dispozici, jen na par mirrorech...
Mimochodem pripojuji se k halasnemu potlesku za nesmirne podareny clanek, jen tak dal. Primluvil bych se za dalsi verze BSD, aspon trochu. -
Mikuláš Patočka (neregistrovaný)
Definice: Mikrokernel je systém, ve kterém ovladače (filesystému, blokového zařízení a sítě) běží v userspace. Ve Windows NT všechny tyto ovladače běží v kernelspace, proto to mikrokernel není. Totéž platí pro MacOS X, BeOS (tam si nejsem jist, kde běží síť. Filesystém je tam určitě v kernelu), takže to též mikrokernely nejsou.
-
Ivona Prenosilova (neregistrovaný)
myslim, ze nejde o ovladace, ale o subsystemy. tj v true microkernel os by v kernelspace mel bezet pouze scheduler + nejaky ipc mechanismus (mozna jeste memory managment) a zbytkove subsystemy os by mely bezet v separatnich procesech.
ok s tim souhlasim, ale ja mluvila o "modified microkernel" :-) mozna pro Vas bude neprijatelne, ze tento termin (zrejme) zavedl Microsoft, ale to je mi vcelku jedno.
NT takes a unique approach, known as modified microkernel, that falls between pure microkernel and monolithic design. In NT's modified microkernel design, operating system environments execute in user mode as discrete processes, including DOS, Win16, Win32, OS/2, and POSIX (DOS and Win16 are not shown in Figure 1). The basic operating system subsystems, including the Process Manager and the Virtual Memory Manager, execute in kernel mode, and they are compiled into one file image. These kernel-mode subsystems are not separate processes, and they can communicate with one another by using function calls for maximum performance.
urcite subsystemy bezi sice v kernel modu, ale maji urcity interface - vysoka modularita _je_ tam proste videt (i v kodu). coz u true monolithic kernels rozhodne neni pravda.
nicmene nechci slovickarit, timto koncim moje prispevky do tohoto threadu. musel byste predlozit velmi padne argumenty, protoze ja svuj nazor mam pomerne dobre podlozeny :-) -
Mikuláš Patočka (neregistrovaný)
A to platí i pro NT 4, 2000 a XP? Já jsem měl pocit, že takhle fungovaly Windows NT 3.5 a verze 4 má už i GUI v kernelu.
Jinak tenhle návrh považuji za nejhorší možný, jaký může existovat:
- bezpečnost nepřináší, když někdo nalezne bugu v subsystému API, ovládne všechny procesy používající tento subsystém --- t.j. celý počítač
- stabilitu také nepřináší, když nějaký subsystém spadne, spadnou všechny procesy ho používající
Na druhé straně to má nevýhody --- pomalost a komplikovanost syscallů.
Nebo to mají uděláno tak, že kopie těch subsystémů se pouští pro každého uživatele zvlášť? Pak by to dávalo smysl, ale nikdy jsem neslyšel, že to tak je. -
Ivona Prenosilova (neregistrovaný)
to plati pro vsechny NT verze. GUI bylo od WinNT 4.0 dano do jadra, ale na idee subsystemu to nic nezmenilo.
bezpecnost ani stabilita neni nijak narusena v porovnani napriklad s *nixem. jsou to proste systemove procesy, takze kdyz je narusite, je jasne, ze ziskate pristup k cele masine (ci userovi - viz dale), tak jako v *nixu (kde afaik zadne systemove procesy v user modu nebezi - prosim opravte mne, pokud se mylim).
pomalost a komplikovanost syscallu? ja bych to nazvala dobry design, ktery mysli na budoucnost a extensionalitu. a ano, dobry design muze v nekterych pripadech prinaset urcite zpomaleni oproti hacknutym zalezitostem. - skoro bych si dovolila parafrazovat NetBSD slogan - we provide solutions, not hacks :-)
nicmene v tomto pripade bude overhead minimalni v porovnani s moznostmi, ktere to prinasi.
jinak samozrejme pro kazdeho uzivatele se subsystemy spousteji zvlast (krome session manageru, ktery ridi sessiony, tady by to asi nemelo smysl :-)). Toto je pravda u WinNT/2k s Terminal Services - od XP jsou TS nativne.
to znamena, ze je urcita mnozina api fci, ktere se zovou nativni, tj fce ktere v podstate (ve vetsine pripadech) pouze via sysenter (nebo drive int 2eh) prenesou vykonavani do jadra. subsystemy exportuji api, ktere v podstate volaji nativni fce s tim, ze jim pridavaji jakousi funkcionalitu navic. a tak se to na sebe krasne bali :-)
http://www.microsoft.com/windows/sfu/default.asp jest prikladem takoveho subsystemu.
