[OS] Coder un nouvel OS, qu'est-ce que on doit recoder ?

Voici un topic, des trucs à tenir et ne pas tenir compte lorsqu'on se lance dans le programmation d'un OS, histoire de démêler ce qui est propriétaire à un OS existant et ce qui est "général" du côté de l'asm et du cpu.

Alors je commencerai donc par cette question: Quelles sont les interruptions indépendantes du OS ? Je supposes que celle du DOS 21h est exclu. Alors il ne reste que les interruptions matérielles qui sont indépendantes du OS si je ne fais pas d'erreur ? :oops:

Est-ce qu'on peut en avoir une liste complète quelque part ? :wink:

Si je comprends bien les interruptions logicielles comme 21h de DOS c'est un genre d'API non ?

Donc je devrais les refaire pour mon OS n'est-ce pas ? :lol:

Donc en effet les interruptions DOS sont exlus car propre au syteme DOS.. Et bien entendus tu devras les reprogrammer :D

Par contre il te reste les interruptions du BIOS (la liste ici: http://www.delorie.com/djgpp/doc/rbinter/ix/ ). Celles-ci seulement utilisable en mode réel (aujourdhui on reste rarement en mode réel donc il te faudra aussi les réécrire (c'est justement ça qui est amusent hein :wink: )).

Pour commencer je te conseil ce site http://inferno.cs.univ-paris8.fr/~am...utorial00.html c'est bien documenté avec des exemples (bien sur une fois le stade de cette doc dépassé tu devra te tourner vers d'autres document car la route qui mène à l'OS perso et longue et semée d'embûches :lol: )

Super :)

Mais pour réécrire les int du bios ? Est-ce bien utile ?? Est-ce que Windows s'en sert par exemple ?

Car une fois en mode protégé ils ne sont plus disponible, mais dans ce mode aussi bien faire un driver de base pour la carte vidéo pour afficher des trucs jolies à l'écran ;)

Ah oui, est-ce qu'un jour on va pouvoir booter directement en mode protégé ? On garde le mode réel pour une compatiblité mais il me semble que les vieux programmes on ne s'en sert plus alors pourquoi garder compatibilité ? Un jour il va bien faloir changer de technologie non ? ;)

Oui quand je disais réécrire les interruptions c'étaient effectivement sous forme de drivers (bien qu'on puisse aussi les faire sous forme de int..)
Windows (ou plutot DOS dans ce cas) se sert des interruptions, l'exemple le plus bête serait quand tu programmes et que tu utilises une interruption :wink: )

Pour le boot direct en mode protégé c'est vrai que ça pourrait être pratique ^^ et que la "trainée" de cette retro-compabilité et assez ancienne, mais il ne me semble pas avoir déjà entendus parler de cette solution de virrer le mode réel (et ça pourrait changer pas mal de trucs ,bon ou mauvais).

Citation:

---

Ah oui, est-ce qu'un jour on va pouvoir booter directement en mode protégé ?

---

J'ai entendu dire que c'est le genre de gadget que l'on pourra trouver dans les bios de nouvelle génération...
Mais si tu fais ton os, tu peux très bien ne faire que du pmode: grub offre la possibilité de démarrer un kernel au format elf 32 bits (et directement en pmode)... ;)

Dans tous les cas, pour tout ce qui est programmation d'os, n'oublie pas de faire un tour régulièrement sur : http://skan.developpez.com/

Ok :)

Mais pour ce qui est des drivers, j'magine qu'il faut avoir les specs du matériel ? C'est sûr qu'une souris de base, par exemple, à 2 boton et une roulette ne poserais sans doute pas de problème, mais si la souris en question est une logitech avec 7-8 boutons, 2 roulettes, etc. Il faut un driver adapté à cette souris la pour pouvoir utiliser tout ces boutons sous le nouveau OS. À ce moment-la comment fait-on ? Il faut demander les specs au fabricant ou leur demander de faire un driver ? :?:

Interessant le boot en pmode (bien qu'il faille alors attendre que ces BIOS se popularisent sinon la fonctionalité restera inutilisable (ou seulement pour quelques privilégiés..)).

En effet il faut les specification matériel du fabriquant (crois pas qu'ils vont t'écrire un driver adapté pour ton OS! à moins qu'il devienne très populaire (comme le cas de linux et de nvidia par exemple..)). C'est pourquoi pour un OS amateur, seul les fonctions de base sont gérés (une petite équipe peut mal géré toute les spécifications de souris à 8touches, clavier à 150 etc :lol: ).

PS: Cool le site skan commence à avoir du continus! :D

Dans les bios ? Je croyais que le mode réel était géré par le cpu ? :?

Plusieures solutions:
:arrow: Regarder dans le noyau linux
:arrow: Si tu as beaucoup de courage, reverser le driver windows de la souris en question
:arrow: Trouver une doc sur le web
:arrow: Demander une doc au constructeur (qui ne te répondra probablement pas du tout, à moins que tu ne fasse partie d'une communauté de création d'os reconnue, ... et encore !)
:arrow: Faire un driver ne gèrant que les trois boutons standards de la souris... ;)
:arrow: Faire tout au pif et avoir beaucoup de chances (et beaucoup de fromages pour pouvoir amadouer cette %#@?! de souris :roll:)
:arrow: Se lier avec un ingénieur de l'entreprise qui fabrique la souris en question
:arrow: Changer de souris et passer à quelque chose de plus facile...

:wink:

Citation:

---

PS: Cool le site scan commence à avoir du continus!

---

Oui oui ca avance 8) Merci de ton soutient ;)

Si j'ai bien compris, une souris multi-fonction ne fonctionne pas sous linux ? :lol:

Ça me surprendrait que MS ait fait un pilote pour linux :wink:

Citation:

---

Si j'ai bien compris, une souris multi-fonction ne fonctionne pas sous linux ?

---

Il me semble que logitech fournit certains drivers sous nux (pas sur...)

Citation:

---

Envoyé par 2PluS4

Citation:

---

Si j'ai bien compris, une souris multi-fonction ne fonctionne pas sous linux ?

---

Il me semble que logitech fournit certains drivers sous nux (pas sur...)

---

Ok :)

Mais en pratique, comment fonctionne un driver exactement ?

Si on prend l'exemple de la souris, si j'appuies sur le 5e bouton qui se trouve sur le "côté" de la souris, il me suffierait d'aller lire sur le port usb non :?:

Citation:

---

Si on prend l'exemple de la souris, si j'appuies sur le 5e bouton qui se trouve sur le "côté" de la souris, il me suffierait d'aller lire sur le port usb non

---

Encore faut il savoir:
:arrow: Ce que t'envoie la souris quand tu clique sur le cinquieme bouton
:arrow: Comment interpreter ces résultats (surement envoyés sous la forme de "blocks" de donnés)
:arrow: Comment activer l'utilisation du 5eme bouton
:arrow: Comprendre quelque chose au standard usb, qui est aujourd'hui considéré mondialement comme une des choses les plus complexes de l'informatique.... (pour être franc, je n'arrive même pas à comprendre le premier chapitre des spécifications .... :roll: )
:arrow: Avoir en tête une structure générique de drivers

Un driver se base sur des spécifications précises du matériel.
Son but est d'interagir avec l'os, sous forme de module, ou à l'interieur du kernel, (selon la structure de l'os), suivant un paradigme de drivers particulier: un "modèle générique" de driver.

Mais il reste quand même que un bouton cliqué n'est rien de plus qu'un bouton, c'est au OS de pouvoir offrir une interface sur l'action que doit prendre l'OS en fonction de ce click, je visualise mal en quoi on a besoin d'un spec sur le 5e bouton ;)

Je serais curieux de voir les specs sur port usb, est-ce que tu aurais un lien ? ;)

Citation:

---

Je serais curieux de voir les specs sur port usb, est-ce que tu aurais un lien ?

---

http://www.usb.org/developers/docs/ Bonne chance :mrgreen: :mrgreen:

Citation:

---

je visualise mal en quoi on a besoin d'un spec sur le 5e bouton

---

Tu en a besoin justement pour que ton driver sache que la souris est en train de lui "dire" que le cinquieme bouton a été enfoncé...

Citation:

---

c'est au OS de pouvoir offrir une interface sur l'action que doit prendre l'OS en fonction de ce click

---

Vi, mais, en gros, c'est le driver qui va "dire" au reste de l'os que le cinquieme bouton a été enfoncé, à partir de ce que lui a envoyé la souris....

Citation:

---

Envoyé par 2PluS4

Citation:

---

Je serais curieux de voir les specs sur port usb, est-ce que tu aurais un lien ?

---

http://www.usb.org/developers/docs/ Bonne chance :mrgreen: :mrgreen:

Il y a plein de Docs, laquelle est la principale ? ;)

Citation:

---

je visualise mal en quoi on a besoin d'un spec sur le 5e bouton

---

Tu en a besoin justement pour que ton driver sache que la souris est en train de lui "dire" que le cinquieme bouton a été enfoncé...

Oui ça va de soi, un driver ne serait donc qu'une routine qui vérifie à toute les secondes si un bouton de la souris à été enfoncé ? Ou si c'est plutôt qu'il faut programmer une interruption matérielle afin de déclencher un évenement de click puis que le Os exécute ce qu'il faut en conséquence, par exemple un click sur un bouton, l'API du OS fera en sorte que le bouton aura l'air appuyé a l'écran puis exécutera la procédure de cette évenement qui aura été programmé par le créateur du programme en question, est-ce que j'ai tout faux ? :lol:

Citation:

---

c'est au OS de pouvoir offrir une interface sur l'action que doit prendre l'OS en fonction de ce click

---

Vi, mais, en gros, c'est le driver qui va "dire" au reste de l'os que le cinquieme bouton a été enfoncé, à partir de ce que lui a envoyé la souris....

---

Est-ce qu'il y aurait une doc quelque part explicant tout le trajet ? du click jusqu'à l'affichage à l'écran :wink:

Citation:

---

Il y a plein de Docs, laquelle est la principale ?

---

Roo mais la première voyons ! :P
http://www.usb.org/developers/docs/usb_20_02212005.zip

Citation:

---

Est-ce qu'il y aurait une doc quelque part explicant tout le trajet ? du click jusqu'à l'affichage à l'écran

---

Non je ne pense pas... Mais tu n'as pas compris ce que j'ai posté ? :roll:

Citation:

---

Envoyé par 2PluS4

Citation:

---

Il y a plein de Docs, laquelle est la principale ?

---

Roo mais la première voyons ! :P
http://www.usb.org/developers/docs/usb_20_02212005.zip

Citation:

---

Est-ce qu'il y aurait une doc quelque part explicant tout le trajet ? du click jusqu'à l'affichage à l'écran

---

Non je ne pense pas... Mais tu n'as pas compris ce que j'ai posté ? :roll:

---

Euh pas tout à fait :lol:

Mais est-ce que j'ai deviné juste comme j'expliquais plus haut ? :wink:

Ok, la je viens d'examiner le code de la page:

http://inferno.cs.univ-paris8.fr/~am...utorial02.html

Mais il y a quelques trucs que je ne comprends pas :?

Dabord, le bios charge le secteur de 512 octets à l'adresse 0000:07C00 exact ? mais comment se fait le Jump vers la première instruction ?

Comment est structuré le fichier .bin, ce n'est pas un format d'exécutable d'un OS, donc quelle est sont format et comment le cpu sait ou se trouve la première instruction ainsi que les données à traiter ?

le code:

Code:

---

1 2 3 4 5 6

mov ax,0x07C0 mov ds,ax mov es,ax mov ax,0x8000 ; stack en 0xFFFF mov ss,ax mov sp, 0xf000

---

pourquoi toute ces instructions ? à quoi ça sert exactement chaque ligne ?

je sais que ça fait mov, mais pourquoi ces opération exactement ??

ensuite il y a:

Code:

---

1 2	end: jmp end

---

NOTE: ça j'ai compris c'est pour mettre le programme en boucle..

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

;--- Variables --- msgDebut db "Hello world !",13,10,0 ;-----------------   ;--------------------------------------------------------- ; Synopsis: Affiche une chaine de caracteres se terminant par 0x0 ; Entree: DS:SI -> pointe sur la chaine a afficher ;--------------------------------------------------------- afficher: push ax push bx .debut: lodsb ; ds:si -> al cmp al,0 ; fin chaine ? jz .fin mov ah,0x0E ; appel au service 0x0e, int 0x10 du bios mov bx,0x07 ; bx -> attribut, al -> caractere ascii int 0x10 jmp .debut   .fin: pop bx pop ax ret     ;--- NOP jusqu'a 510 --- times 510-($-$$) db 144 dw 0xAA55

---

ça aussi c'est pour la signature et remplir le reste du fichier .bin

Mais le reste ? pourquoi jouer avec la pile au juste ?

Svp, éclairez ma lanterne :wink:

Merci :)

Citation:

---

Dabord, le bios charge le secteur de 512 octets à l'adresse 0000:07C00 exact ? mais comment se fait le Jump vers la première instruction ?

---

Un truc à savoir: le bios c'est en gros une suite de programmes en mode réel... Donc à un endroit donné du bios, on a un code qui copie le secteur de boot à 0x0000:0x7C00 et juste parès, on a un ptit jmp 0x07C0:0000 ! Ou quelque chose d'approchant ... ;)

Citation:

---

Comment est structuré le fichier .bin, ce n'est pas un format d'exécutable d'un OS, donc quelle est sont format et comment le cpu sait ou se trouve la première instruction ainsi que les données à traiter ?

---

:arrow: Sa structure: pas de structure :P (a part peut être le fait que les octets 510 et 511 doivent être égaux à 0x55 et à 0xAA....)
:arrow: La première instruction est tout simplement la première instruction à l'adresse 0x7C00

Citation:

---

pourquoi toute ces instructions ? à quoi ça sert exactement chaque ligne ?

---

Dans ce code, on initialise les registres de segment... Pourquoi ?
:arrow: Pour ds et es: on init à 0x07C0 pour pouvoir avoir accès au données enregistrées à partir de 0x7C0:0x0000, c'est à dire 0x0000:0x7C00
:arrow: pour ss: ben pour définir une stack ....
:arrow: Si tu ne comprend pas bien, relis tes cours sur l'asm !!! Es tu sur d'avoir bien assimilé la notion de segmentation ?

Citation:

---

ça j'ai compris c'est pour mettre le programme en boucle..

---

Vi, en effet.. ;)

Citation:

---

ça aussi c'est pour la signature et remplir le reste du fichier .bin
Mais le reste ? pourquoi jouer avec la pile au juste ?

---

Tu parles de

Code:

---

1 2	push ax push bx

---

et de

Code:

---

1 2	pop bx pop ax

---

?
On sauvegarde et restaure les registres ax et bx car la fonction "afficher" les utilise...

Mais quelle est l'instruction à l'adresse 0000:07C00 ? Mov ax, 07C0h ??

Donc les instructions se trouve dans le même ordre que je l'ai écrit ? :)

Citation:

---

Mais quelle est l'instruction à l'adresse 0000:07C00 ? Mov ax, 07C0h ??
Donc les instructions se trouve dans le même ordre que je l'ai écrit ?

---

Oui :D

J'essaye de tracer mon code afin de vérifier ce qui se passe exactement, mon fichier.bin contient exactement:

B8C0078ED88EC0B800808ED0BC00F0BE1700E81200EBFE48656C6C6F20776F726C6420210D0A005053AC3C007409B40EBB0700CD10EBF25B58C3

avec une suite de 90909090 ...55AA

Comme l'instruction mov ax, 07C0h se trouve au début quelle est-elle exactement en base 16 ? elle fait combien d'octet ? est-ce B8C0078E du début ou plus ou moins d'octets ??

J'ai essayé de trouver les équivalences en binaire des instructions dans la doc Intel mais je n'ai pas trouvé, c'est dans quel volume ? ;)

Citation:

---

J'ai essayé de trouver les équivalences en binaire des instructions dans la doc Intel mais je n'ai pas trouvé, c'est dans quel volume ?

---

Volumes 2A et 2B ;)

Waahhh :o

Je ne comprends rien :lol:

Je m'attendais plus à un truc du genre: mov == 01101110 et la dépendamment des opérandes d'autres égalités :wink:

Saurais-tu me guider un petit peu ? :wink:

Citation:

---

Je m'attendais plus à un truc du genre: mov == 01101110 et la dépendamment des opérandes d'autres égalités

---

LOL mais tu sais l'asm c'est sensé être compliqué :P

Citation:

---

Je ne comprends rien (...)
Saurais-tu me guider un petit peu ?

---

:arrow: Pourquoi ne comprends tu pas ? C'est parce que la doc est en anglais ? Que il y a trop de choses à lire ? Que tu trouves que c'est mal expliqué ? Qu'est ce que tu ne comprends pas en particulier ?
Qu'est ce que tu as compris de l'organisation de la structure des instructions x86 ? (le chapitre du début) ? Pourrais tu en faire un résumé ?
:arrow: Comment as tu fais ton approche avec la doc ? Je te conseille ca (sérieusement) : commencer par le début, et finir par la fin :D Tu verras, ca prendra peut être beaucoup de temps, mais après, tu comprendras parfaitement tout, dans les moindres détails... Peut être serait il interressant que tu nous/me fasse part de tes avancées, dans ce topic, en précisant bien quelles ont été tes difficultés...
:arrow: Tu ne trouveras pas d'autres docs, c'est la seule qui existe...
:arrow: Tu sais, tu ne comprendras pas toute cette doc d'un coup ! :lol:

:wink:

Je comprends l'anglais, assez pour le lire en tout cas :lol:

Par exemple quand je lis le volume 2B déjà ça: ModR/M byte

je ne sais pas ce que c'est, c'est du chinoix :lol:

Il y a aussi

OPCODE MAP
D The reg field of the ModR/M byte selects a debug register (for example,
MOV (0F21,0F23)).
E A ModR/M byte follows the opcode and specifies the operand. The operand is either a
general-purpose register or a memory address. If it is a memory address, the address is
computed from a segment register and any of the following values: a base register, an
index register, a scaling factor, a displacement.
F EFLAGS Register.

par exemple je n'ai aucune idée à quoi ça sert. Comme je disais je m'attendais plus à quelque chose du genre: Mov == 01101001

:wink:

Je crois que je vais faire comme tu dis, je vais lire et au fur et à mesure si j'ai des questions je vais les poster ici, ça deviendra une analyse de la doc Intel ce topic :wink:

Citation:

---

Par exemple quand je lis le volume 2B déjà ça: ModR/M byte

---

Rooo mais c'est simple, voyons !! :P C'est normal que tu ne comprennes pas si tu commence par la partie 2B (et pas 2A) !! :D

Je me demandais une chose, est-il possible de faire un code en binaire pur et l'éxécuter sous un OS ? Par exemple windows ? J'imagine que dans le mieux que je pourrais faire serait de créer un exe Win32 pour Jmp sur à l'adresse de mon binaire pur, autrement comme dire à Windows d'exécuter mon code ? :wink:

J'aurais aimé faire un petit jeu de pong exécutable sur tout les OS pour x86 en le faisant en binaire pur.

Citation:

---

J'aurais aimé faire un petit jeu de pong exécutable sur tout les OS pour x86 en le faisant en binaire pur.

---

Alors il te faudra un binaire par os (sans compter les compatibilités du style freebsd/nunux)...

Citation:

---

Je me demandais une chose, est-il possible de faire un code en binaire pur et l'éxécuter sous un OS ? Par exemple windows ? J'imagine que dans le mieux que je pourrais faire serait de créer un exe Win32 pour Jmp sur à l'adresse de mon binaire pur, autrement comme dire à Windows d'exécuter mon code ?

---

Sur windows ca va être chaud !! Par contre sur nux (qui utilise une int pour les syscalls, donc plus facile à utiliser), et avec un ptit format elf modifié (pour être plus simple), c'est très faisable !
Mais bon, le principe est interressant...
:wink:

C'est incroyable, j'apprends plein de trucs ici :lol:

Merci à vous tous :wink:

Mais pourquoi un binaire par OS ? c'est du binaire pur donc ça devrait fonctionner sur tout les OS non :?:

Citation:

---

Mais pourquoi un binaire par OS ? c'est du binaire pur donc ça devrait fonctionner sur tout les OS non

---

Un binaire pur ne fonctionnera que lorsque tu démarre toi même le PC.

A partir du moment où un OS digne de ce nom est lancé (cela exclu bien entendu MS-DOS), tu ne peux plus faire ce que tu veux. Windows, *BSD, Linux, KOS ... (bientôt Skan ...) passent en mode protégé, et créent des protection et des normes à respecter pour les acces à la mémoire, aux périfériques, aux systèmes de fichiers ...

Les acces aux périphériques (la carte vidéo par exemple) ne se font pas de la même manière sous Linux que sous Windows ... donc tu ne peux pas avoir le même binaire, ni le même code (à moins que tu travaille en C, Java ...)

sdx

ps: comment ça j'explique mal :twisted: ?

Merci :)

En ce qui me concerne, tu expliques très bien :D

Donc je pourrais faire une série de jeu style Nintendo 8 bit qui fonctionnerait en binaire pur au démarrage du PC ? :wink:

Un peu comme les vieux Apple IIe ou il fallait mettre une diskette de jeu au démarrage du PC :lol:

Ça c'était géant :wink:

Avec Bochs les gens pourront jouer à mes jeux sous Windows :wink:

La j'ai un deuxième ordi, je vais le brancher pour tester le bootloader c'est idéal, parce que Bochs bug parfois :)

Skan ? C'est une nouvelle distrib linux ??

Par contre, si je veux accéder à plus de 1mb de mémoire il va faloir je passes en mode protégé n'est-ce pas ?

Sur ce, si je fais un noyau, je dois passer en mode protégé (avant) de le loader ? Mais pour loader un fichier en mémoire, car le noyau n'est qu'un fichier en binaire pur que l'on a fait, j'imagine que tout les noyaux sont en binaire pur non ? Sinon je vois mal comment on peut faire exécuter un exe ou un format de fichier précis à un OS avant que son noyau soit chargé :lol:

Mais pour cela, comment on charge un fichier en mémoire et ensuite y faire un jump ? Et il faut savoir aussi ou il va se retrouver en mémoire avant de faire un jump aussi. Sur le chargement du noyau je suis un peu perdu :lol:

Citation:

---

Skan ? C'est une nouvelle distrib linux ??

---

Tu n'as pas lu la signature de 2PluS4 ? http://skan.developpez.com

Citation:

---

Par contre, si je veux accéder à plus de 1mb de mémoire il va faloir je passes en mode protégé n'est-ce pas ?

---

Oui.

Citation:

---

Sur ce, si je fais un noyau, je dois passer en mode protégé (avant) de le loader ? Mais pour loader un fichier en mémoire, car le noyau n'est qu'un fichier en binaire pur que l'on a fait, j'imagine que tout les noyaux sont en binaire pur non ? Sinon je vois mal comment on peut faire exécuter un exe ou un format de fichier précis à un OS avant que son noyau soit chargé Laughing

Mais pour cela, comment on charge un fichier en mémoire et ensuite y faire un jump ? Et il faut savoir aussi ou il va se retrouver en mémoire avant de faire un jump aussi. Sur le chargement du noyau je suis un peu perdu Laughing

---

Ah ... je regrette d'être si lent : je suis justement en train d'écrire de la doc sur le sujet, mais elle n'est pas terminée :wink: En résumé :

• Tu peux faire ce que tu veux, il suffit que tu saches comment faire :roll:
• Grub te permet de charger directement un noyau au format exe elf.
• Pour charger un noyau, tu dois savoir où il se situe sur le support (disque dur, disquette), puis le charger en mémoire à l'adresse que tu veux, puis l'executer (avec un jump, en effet)

Vaste sujet ...

À l'adresse que je veux :o

Mais ce n'est pas illégal au cpu ? Je pourrais écraser des données importantes non ? :wink:

Si grub permet de charger un elf cela veut dire qu'il a le loader elf d'inclus dans son code. :D

Citation:

---

Envoyé par AsmCode

À l'adresse que je veux :o

Mais ce n'est pas illégal au cpu ? Je pourrais écraser des données importantes non ? :wink:

---

ADRESSE | DESCRIPTION

0000:0 Table des interruptions
0040:0 Bios Data Area
0050:0 LIBRE
A000:0 Mémoire vidéo (VGA)
B000:0 Mémoire vidéo
B800:0 Mémoire vidéo
C000:0 Espace réservé au BIOS

Tu n'as le droit d'ecrire que dans la partie LIBRE, c a d entre 00500 et 99999.

Citation:

---

Si grub permet de charger un elf cela veut dire qu'il a le loader elf d'inclus dans son code. Very Happy

---

à verifier, mais je crois bien que c'est ça ...

Ok je vois :)

Dit-moi est-ce que tu as msn ? j'aimerais bien t'ajouter à mes contacts, on pourrait discuter assembleur :wink:

Mais ça ne répond pas à ma question :lol:

Comment on "charge" le noyau en mémoire ? Dans le cas du bootloader c'est le bios qui le fait, mais pour le noyau on doit le charger soi-même, mais comment on fait pour transférer du disque dur à la mémoire un fichier quelconque ?

À propos: noyau == kernel :?:

C'est le bootloader qui se charge de charger le noyau, ou de charger un loader intermédiaire chargé lui même de charger le noyau ! :P
on utilise en général l'int 0x13 du bios pour ca!

Citation:

---

noyau == kernel

---

non pas tout à fait puisque "noyau" c'est un mot français alors que "kernel" c'est un mot anglais... :P Mais sur le principe c'est pareil !

Citation:

---

Si grub permet de charger un elf cela veut dire qu'il a le loader elf d'inclus dans son code.

---

Vi vi c'est ca :D