shrike je napisao/la:I nema tragova od ostalih kernela? milsim, to bi trebalo biti vidljivo negdje. Što kaže za uname -a
Ma dmesg, uname ti ne mogu reći ništa čak i ako je sve ovo što su naveli istina. Zašto?
Iako će to pisati urecenziji, malo ću ovdje objasniti kako su Egipćani to zamislili.
Naime, ovdje se radi o tzv Caching kernel konceptu u kojem postaje supervisor kernel, dotični X-mod koji je Caching kernel. On učitava ostala tri kernela (GNUMach, LS i Linux) po potrebi!
E sad, kako je Linux jedini kernel koji komunicira s userspaceom, logično je da komanda iz userspacea, kao npr. uname ili dmesg može vidjeti samo Linux jezgru, a ostale dvije (GNUMach i LS) ne vidi jer svi sistemski pozivi od strane npr dmesg-a preko X-mod-a završe samo na Linux kernelu.
Zapravo, uopće ne vidim svrhu preostala dva kernela osim na samoj kernel-razini. Npr. Ako dođe do potrebe kopiranja nekog dijela RAM-a jer to zahtjeva neka Linux aplikacija, onda bi X-mod trebao odlučiti da za tu radnju upotrijebi brži LS kernel, a ne Linux, a Linux kernel samo pročita vrijednosti skopirane memorije i vrati to aplikaciji.
E sada, da li to uopće radi ili se radi o samo nekakvim hoaxovima, ne znam. Moja ispitivanja idu u prilog tome da je ovo jedan veći fake.
U slučaju da Caching kernel doista radi i isti preusmjerava I/O i AIO radnje bržem GNUMachu, a radove s memorijom LS kernelu, ne bi li onda kopiranje datoteka ili kompresija istih trebale biti brže na SPhinuxu u odnosu na neku drugu pure Linux distru? Moja ispsitivanja pokazuju potpuno jednaku brzinu kopiranja, a kompresija je čak sporija u odnosu na sličnu distru.
Zbunjuje me nešto drugo, a to je potrošnja RAM.-a.
Nego. Još nešto. GRUB poziva direktno vmlinuz image. Sada, jedino ako u taj vmlinuz nisu zbildali osim linux kernela i LS i GNUMach i X-mod. No u tom slučaju takav image bi trebao biti veći od 2,6 MB koliki je ovaj, a taj je pak manji po veličini od Debianovog kernela.
Tražio sam objašnjenje, pa sad čekam
