Aoleu vai! Chip.
A fost acum vreo 2 ani un articol pe Chip care spunea ca FreeBSD este o distributie de Linux. Asta spune tot despre profesionalismul lor. Chip este o revista foarte slaba. Parerea mea este ca nu merita cumparata. Prin ‘96-‘97 da—era o revista de calitate (desi cu mult sub BYTE), dar acum nu.
In primul rand problema pusa nu are sens. Care kernel e “mai bun” e intrebare de gradinita—de copii care nu au altceva mai bun decat sa se contrazica
. Fiecare kernel are un scop. Este adevarat ca scopurile diferitelor kerneluri sa corespunda in anumite puncte, dar asta nu inseamna ca se poate pune problema “de a fi cel mai bun”. Kernelul QNX este fenomenal pentru dispozitive real time si embedded, asta face QNX mai bun ca orice altceva? NU! In Workloaduri obisnuite kernelul QNX tuseste. Solaris si Linux scaleaza mult mai bine ca XNU pe masini SMP/NUMA cu mai mult de 128 CPU. Asta face Solaris mai bun ca Mac OS X? Nu, il face mai bun doar pentru anumite taskuri.
Ideal este sa folosesti scula potrivita la taskul potrivit, pentru ca niciun OS nu le va face vreodata la fel de bine pe toate.
Acestea fiind spuse mentionez ca scriu si am scris drivere si kernel mode software pentru Solaris, BSD, Linux si Windows. De Mac OS X inca nu am scris inca dar as zice ca sunt destul de familiar cu kernelul XNU sa-mi dau si eu cu parerea
.
Pentru inceput BSOD vs. Kernel Panic. Sunt acelasi lucru. In majoritatea sistemelor UNIX, mai ales cele cu BSD heritage se apeleaze functia panic() din kernel. In Windows se apeleaza functia KeBugCheck(). Functiile astea opresc executia kernelului intr-o maniera controlata. De obicei fac dump la toata memoria sau la o parte esentiala pentru a putea folosi un debugger sa vezi ce s-a intamplat.
Lumea are impresia ca BSOD-urile astea provin dintr-un taram magic, dar de fapt realitatea este ca functia pentru panic() este apelata controlat cand sistemul este adus intr-o stare inconsistenta si nu se mai poate garanta executia determinista a sistemului in continuare. Ar fi foarte usor ca programatorii kernel mode sa ignore ce se intampla in jurul lor si sa nu apeleze panic(), si de multe ori sistemul ar mai functiona, dar pot sa apara pierderi de date si coruperi ale structurilor sau codului din kernel ce pot avea repercusiuni grave, asa ca se prefera ca sistemul sa fie terminat controlat.
Referitor la accesul la hardware (si la placa grafica in mod special)... Orice sistem de operare acceseaza placa grafica in mod direct—evident. In ring 0 ai acces la toate resursele sistemului. Acolo e taramul driverelor ce fac legatura dintre anumite functii GDI si DirectX si hardware-ul in cauza. Asta pe Windows. Funny ca in UNIX (cu exceptia Mac OS X) nu e chiar asa. In cel mai bun caz exista drivere pentru framebuffere, dar care au o functionalitate minimala comparativ cu ce e in Windows si Mac OS X. In UNIX modulele Xorg au nevoie de un hook in kernel pentru a putea implementa drivere accelerate.
Bineinteles ca in niciun sistem de operare din lumea asta nu o sa ai acces la hardware din user space, si trebuie sa treci prin niste interfete exportate de drivere, cum sunt hookurile DirectX din kernel. Am trecut de aceasta epoca neagra in momentul in care am trecut de la DOS la altceva.
In mod cert Compiz ruleaza la fel de bine pe orice sistem de operare pe care ar rula, fie ca e Mac OS X sau Windows, dar compiz nu e portat pe altceva decat Xorg, adica Linux, partial BSD si Solaris asa ca nu are rost sa discutam.
Kernelul XNU este din punct de vedere arhitectural un kernel minunat. Are capabilitati de microkernel, spre deosebire de Linux si Windows care sunt kernele monolitice. Asta nu inseamna ca microkernelele sunt mai bune—dimpotriva. Din punctul de vedere al performantei sunt mai slabe decat kernelele monolitice pentru ca implica foarte mult overhead prin layere aditionale care fac context switching invalidand cache-ul CPU. De asta Mac OS X ruleaza ca un kernel monolitic cu interfata exportata de kernel, BSD subsystem, stiva de retea si extensiile de kernel toate in ring 0 in acelasi spatiu virtual de adresare. Totusi, unele chestiuni non performance critical isi au locul intr-un task mach, si parerea mea este ca OS-ul ar fi avut numai de castigat din asta.
Kernelul XNU mai are avatajul de a nu folosi 2/2 address space split ca alte sisteme de operare cand ruleaza pe 32bit, aplicatiile avand mai multa memorie, dar are dezavantajul de a face context switching la fiecare syscall in kernel.
Din pacate XNU este 32 bit only, desi ruleaza binare pe 64bit fara probleme. Sa speram ca la Snow Leopard o sa avem un sistem pur 64 bit.