Francois-Xavier KOWALSKI wrote:
> Autant que je sache, MkLinux n'est _pas_ un Linux, mais un micro-noyau
> qui accepte avec assez peu de bidouilles les drivers & autres
> sur-couches directement issues de Linux. Si je raconte des conneries,
> n'hésite pas à me corriger.
Je n'hesite pas ;-)
En fait MkLinux est Linux de la meme maniere que LinuxPPC, Linux Alpha et
Linux M68K sont linux
(mais au risque de me faire blamer, je dirais que le commun des utilisateurs
de PC est a mille lieus de s'en rendre compte,
au passage de je tiens a faire remarquer que les developpeurs i386 ont encore
casse la portabilite vers PPC a partir du noyau 2.2.9: l'OpenSource, c'est
bien, mais c'est l'anarchie)...
En fait ce n'est que la couche basse qui change: l'interface avec le hard.
Sur les implementations standards, l'interface se fait directement (en
fonction de l'architecture, /usr/linux/arch/) alors que avec MkLinux
l'interface se fait par l'intermediaire de ce qui est reellement le
micro-noyau, dans notre cas un micro-kernel Mach (qui est aussi repris par le
projet GNU Hurd, et le projet Rhapsody Apple (MacOS X) issu de NextStep, en
plus je crois que certaine boite comme Oracle ou un informix cherche se
debarasser des OS et implementeraient directement leur database sur
micro-noyau Mach-> performance acrues, portabilite)
Les avantages de la methode:
portabilite d'une architecture a l'autre, on adapte juste le micro-noyau, les
couches hautes ne changent pas
eviterait l'anarchie puisque l'interface Mach fait l'objet d'une
specification precise.
Les inconvenients:
Les couches hautes et le micro-noyau communiquent par messages ce qui
engendre une charge supplementaire
(par exemple, mon PowerBook sous LinuxPPC affiche 499 Bogomips alors que sous
MkLinux il en affiche seulement 299)
Tout ce qui est couche basse (pilote de carte, memoire vituelle) echappe au
couche haute: d'ou, comme tu le dis, plus de bidouille de driver au niveau
MkLinux, mais ca revient a porter un driver sur une nouvelle architecture. En
plus, c'est peut-etre aussi une consequence, les modules ne fonctionnent pas.
Autre inconvenient, il y a beaucoup moins de ressource (homme/an) engagees
sur ce projet, et le noyau (du moins la release DR3 d'apple) est beaucoup
moins robuste.
A+
Laurent
--
--------------- Laurent Vivier --------------
mailto:Laurent@Vivier.grenoble.hp.com
phone: 04 74 99 32 96 telnet: 769-3296
---------------------------------------------
UNIX is user-friendly...
It's just selective about who its friends are
---------------------------------------------
