Zainteresovani da napisemo jedan simple OS zajedno?

I tako...

---

I? Šta sada?

Hajde, ima tu stručnjaka koji bi mogli da započnu jedan domaći "minix". Zašto ne.

Treba nam neko ko će da hostuje, nekoliko majstora koji će da započnu razvoj i određuju ko može da učekira kod, i lagano.

Slazem se da bi pokusaj pisanja nekog i najjednostavnijeg OS-a bio samo u neke
edukativne svrhe, i to bi bilo zanimljivo videti, jer bi se redom postavljala pitanja koja
su bitna da bi se napravio jedan OS, a to je najbitnije, da ljudi uopste znaju koja pitanja
sebi treba da postave kada jedna takva ideja u pitanju....
Znaci, ako hocete tako nesto da uradite pocnite sa definisanjem nekih zahteva sta
taj OS treba da radi, na cemu mora da se izvrsava, kakvo user okruzenje treba da
ima i tako dalje.... Dakle, dajte neke definicije odakle poceti...

(recimo u c-u se moze napisati kratak program koji ce da pristupa nekom
hardveru u low levelu, ali to ne znaci da je to OS...
Znaci, definisite bar neke osnovne postavke prema hardveru i prema
korisniku... a onda se moze razmisljati sta treba da se smesti izmedju, tj,
kakav OS da se pravi)

---

Iako sigurno nisam stručnjak, izuzetno sam zainteresovan, pre svega da naučim nešto novo.

Evo „kako bih ja to...“  (uzeti uslovno, ovo stvarno samo hipotetički raspravljam, da vidim ko šta misli)

Kernel specifikacija (predlog):

- mikrokernel
- ciljna arhitektura: PC-IA32 (a može da se „misli“ i na druge, ali ne bih gubio vreme pokrivanjem svega, ovo ipak treba da bude hobi projekat).
- Memory model: „flat“. To sam „naučio“... ostale varijante su manje dobre. Potpuno iskorišćenje MMU, sa straničenjem (ali bez virtuelne memorije, odnosno da budem precizan, bez „swapping“). Uobičajena stvar: kernel u 4Mb stranama, aplikacije u 4Kb ili 4Mb, da bude konfigurabilno. Razlikovanje strana sa kodom, stekom, podacima i naravno zaštita.
- Fleksibilni scheduler. Da može da se relativno lako prekonfiguriše, i da može da se bira strategija za različite aplikacije/niti. Ovde samo da stavimo infrastrukturu za proširenja, a implementiramo samo uobičajene „round robin“ ili tako nešto. Možda čak da scheduler bude na nivou drajvera???
- Kompajler: GCC
- Bar 3 nivoa privilegija: kernel, drajveri, aplikacija (drajveri obavezno da budu van kernela, ali bih da ne budu ni na user-nivou... ili se ovime ne dobija mnogo?)
- IPC: ??? da se odredi... MessagePassing, nešto drugo ili i ovo i ono... Sada, da ne bi ponavljali nešto kao MINIX (u protivnom možemo samo da se uključimo u taj projekat), koji bi IPC koristili? „Message passing“ je ono što, kako vidim, najčešće ljudi koriste. Ali da li može bolje (brže) a da drajver/kernel i dalje budu u različitim ringovima, mislim daje to jako važno. Samo, za razliku od MINIX, QNX i slično ne bih stavio drajvere u user space, treba ipak da budu malo teže pristupačni. Intel ima 4 nivoa privilegija, zašto ne bi koristili još jedan osim 0 i 3. Message passing može da bude usko grlo u recimo multimedijalniim aplikacijama gde drajver mora da isporučuje „streaming“ podataka aplikaciji. Kako ovo uraditi?


Glavna razlika od većine ostalih kernela: ono o čemu dosta razmišljam jeste da API ne bude POSIX. Odnosno, da preciziram: POSIX sloj moramo da obezbedimo kasnije da bi mogli da iskoristimo čitav GNU projekat, ali na najnižem nivou bih probao da ponudim objektno-orijentisani API (ovo možda lupam, ali tako „Perica zamišlja kako bi to trebalo“). Vidim da ljudi iza HURD projekta sanjaju o sličnom.

Moja ideja je da kompletan API iz kernela bude preko interfejsa (interfejs u smislu viših jezika kao na primer u C++ abstraktna klasa ili, još bolje, u CORBA simslu ili COM smislu interfejs). I ovo je slično onome što pokušavaju ljudi iza HURD kernela. Do sada nisu uspeli... mada ne znači da nije moguće. Ja sam uveren da jeste.

Interfejsi se definišu u nekoj vrsti IDL (Interface definition language) što sa odgovarajućim kompajlerom (postoje „slobodni“ kompaleri za ovo) prave hedere za C, C++ ili već šta je jezik implementacije. Na najnižem nivou, interfejsi bi radili kao u C++, odonosno bila bi to neka tabela virtuelnih rutina. Sve što „radi“ na ovoj platformi kreće od toga (za POSIX aplikacije ovo bi bilo urađeno jednom, a implementacija POSIX sloja i C-rantajma bi ispod haube koristila interfejse; POSIX aplikacija ne bi toga bila direktno svesna, osim ako programer „zna šta radi“, moći će da koristi ove interfejse direktno).

Dakle, kernel „nudi“ API u vidu objekata. Objektna hijerarhija bi bila zapravo hijerarhija interfejsa.

Pri inicijalizaciji procesa (sve bi bilo po procesima, uključujući i drajvere, mislim da je dokazano da je to dobar pristup), kernel startuje proces sa inicijalizovanim pointerom za određeni interfejs ka kernelu. To je minimum, svaka aplikacija kreće od toga.

Ovo bi verujem dalo fantastične mogućnosti: na primer, za debugovanje možemo u toku rada drajvera da mu „podmetnemo“ proksi koji bi radio logging, kada završimo sa debugovanjem, „izbacimo“ logging proksi iz pozivnog niza a drajver „ne ukapira ništa“ i sve to bez reseta restarta ili sličnog. Tako barem zamišljam. Dalje, mogli bi na ovaj način da napišemo drajver koji bi bio pisan za jednu mašinu, a da kernel u pozadini distribuira rad na više (na primer nekoliko računara koji rade pod timom kooperativnih kernela)... Možda suviše letim, ali eto to bih stvarno voleo da probam. Cena ove fleksibilnosti bi bio ekstra nivo redirekcije jer bi sada aplikacija „zvala“ drajver odnosno API operativnog sistema preko ekvivalenta virtuelnim pozivima u C++. Mislim da je to u redu, da je fleksibilnost vrednija.

Primer kako bi to izgledalo u C++ aplikaciji (hipotetički „obavezni“ interfejs aplikacije bi bio negde deklarisan kako extern, i recimo da se interfejs zove IKernel.. a da se rutina zove SendMessage ):



Eto. Mišljenja?


_{[Ovu poruku je menjao etoxiuq dana 01.08.2007. u 17:42 GMT+1]}