Vlákno názorů k článku HelenOS nikdy nebude dokončený, říká jeho autor Jakub Jermář od anonym - A odvozeně též kromě Mac OS X i...
-
JaGa (neregistrovaný)
To ne Hurd je GNU GPL takže nelze použít pro uzavřené projekty.
V MAC OS X je použit XNU což je kombinace kernelu BSD a Mach.
http://upload.wikimedia.org/wikipedia/commons/f/f2/Diagram_of_Mac_OS_X_architecture.svg
-
>> V MAC OS X je použit XNU což je kombinace kernelu BSD a Mach.
Když už je o tom řeč, máte někdo představu o tom, proč vlastně Apple BSD jádro nad ten mikrokernel posadil (podobně jako MS)? Kvůli nějaké teoretické budoucí rozšiřitelnosti o jiné machovské subsystémy? Už toho někdy využili, nebo to alespoň plánovali? Pokud vím (a moc toho o tom teda nevím :), i věci, kde bych to tak nějak čekal (Grand Central Dispatch) běží až nad BSD kernelem...
A MS? Ten už mikrokernel nějak pořádně využil?
-
toTem (neregistrovaný)
GCD je implementovany nad BSD/Posix API proste proto, ze pouziva Posix pojem jako semafor a umoznuje aplikacim standartne ridit flow mezi execution units ("thready") nejakeho tasku, tj. pro Posix aplikaci se nemeni struktury - navazane na zbytek Posix API - pro rizeni toku programu, ale "jenom" identifikace jednotlivych paralelizovatelnych exexcution units (funkci/bloku/...). Aplikace potom resi jenom identifikaci/rozdelovani prace, nikoliv jejich mapovani do fyzickych threadu potazmo procesu... vyhoda je jasna: nemusim resit konfiguraci pro kazdy stroj, procistil/zkratil se mi kod, aplikace je regulovana momentalni dostupnosti CPUs/zdroju OS bez meho zasahu, tj. spravu a kontrolu obsazenosti thread-poolu deleguju na GCD...
Jeho implementace je tak take prenositelna (http://libdispatch.macosforge.org) mezi Posix-like OS, tedy aby jej mohly vyuzit standardni POSIX aplikace bezici na *BSD, dokonce s upravami i na Linuxu a NT - tady ale mame omezeni vyplyvajici z nutnosti pouzit Clang compiler.
Jinak hlavni motivace pouzit mikrokernel pro OSX (mozna obecne) je primarne potreba lepsich struktur pro stavbu OS. User-space ma dost prostredku zavest libovolnou potrebnou miru abstrakce, ale vetsine OS vcetne Linuxu takova vnitrni struktura chybi. OSX je hybrid ponechavajici cely VFS i network stack na implementaci od BSD, ale diky Machu pod prdeli se muzou kdykoliv rozhodnout postavit dalsi mezivrstvu mezi vlastnim HW a vyssim subsystemem i mezi subsystemy navzajem. Tj. umoznuje jim to lepsi interceptovatelnost. To ze se rozhodli nechat bezet Mach a BSD spolu ve stejnem adresnim prostoru (nezabere memory protection z procesoru) a oboje v ring0 chapu "jenom" jako performance benefit... rozpojit to _lze_.
Predstavte si jak by mohli implementovat Spotlight (fulltext search nad objekty v systemu, pro jednoduchost nad soubory): zadny z FS (a dejme tomu ani VFS) to nepodporuje, tj. nerozesila eventy o vytvoreni/presunu/smazani/... souboru. Pak muzu na vstupu do Posix callu vytvorit kontext kde zaznamenam o jaky soubor a jakou operaci se jedna a jakmile BSD/(V)FS provede zapis, dostane se do Machu message s pozadavkem na konkretni ukon nad driverem. Tuhle I/O (Kit) zpravu muze ale v mikrojadru zachytit i muj spotlight-events-listener, ktery ji na zaklade obsahu kontextu muze zpracovat (upravit svuj index). Takhle transparentne mam poresene vsechny FS v systemu aniz to kterykoliv z nich tusi... a ano - tuhle featuru by jste mohl implementovat i na urovni BSD kernelu a jeho VFS, ale v pripade ze se Apple rozhodne zamenit BSD za Linux (:-)), bude fungovat bezezmeny dal... obdobne mohou takhle implementovat transparentni cache, ..., pro cokoliv mezi HW/BSD.
Apple kernel development docs: http://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/KernelProgramming
-
Díky moc za obšírnou odpověď.
V podstatě jsem to teda zas tak moc nepřestřelil: Mach použili proto, aby v budoucnu *mohli* udělat nějaké zajímavé věci, ale zatím toho moc nevyužili.
V tom seriálu, co je tady, se píše jenom krátce o lepší kontrole nad drivery - jsou i nějaké další příklady toho, co reálně (ne jen potenciálně) využívá výhod Machu pod BSD kernelem?
-
martin (neregistrovaný)
Moc nerozumím otázce, ale BSD použili jednak aby zefektivnili některé úlohy a aby získali POSIX API. Krom toho vytáhli z BSD řadu dalších vlastností (VFS, síť, audit, MAC, atd.)
Na druhou stranu důvodem pro použití Mach kernelu byl jednak NeXTSTEP a jeho výborné vlastnosti jako stabilita a vyzrálý SMP (mluvíme o 2. polovině 90.let) a také jeho Mach object formát tedy krom jiného využili jeden "exe" pro více architektur - přinejmenším PPC, Intel příp. ARM. Mach dělá v Darwinu vlákna, multitasking, procesy (ty jsou v BSD vrstvě "předělané" do unixového modelu), RT, IPC (opět v BSD vrstvě transformované na sys-v IPC) atd.
ČLÁNKY DO MAILU
