Peut-on écrire un kernel en C++ ?

**Melem** · 17/02/2009, 07h38

Envoyé par amaury pouly

De plus, écrire un noyau en C standard relève de l'exploit. Quelques problèmes:
* Alignement des structures
* Assembleur "inline"(ça peut être utile)
Toutefois c'est vrai qu'une fois ces quelques désagréments passés, le reste c'est du C tout ce qu'il y a de plus standard.

Voilà. C'est bien ce que je voulais soutenir. Et je l'ai déjà d'ailleurs dit, le C utilisé pour écrire un noyau peut rester 100% standard, ce sont les outils à utiliser qu'il faut bien choisir. On ne compile pas un noyau avec n'importe quel compilateur. Il y a des outils spécialisés. J'ai déjà donné des exemples. L'assembleur en ligne n'est pas obligatoire, c'est juste une facilité qu'on aime utiliser (pariel pour la plupart des fonctionnalités non standard généralement utilisées ...). On peut très bien développer toutes les routines dont l'implémentation dépendent d'une plateforme particulière en assembleur et appeler ces routines depuis le C.

Envoyé par Médinoc

Hum...
À ma connaissance, il est impossible d'écrire entièrement un noyau en C ou en C++, car ces langages n'ont rien pour gérer les interruptions...

Dans tous les cas, il faut à bas niveau des fonctions écrites directement en assembleur.

Bien sûr. Tout n'est pas écrit entièrement en C. C'est le noyau (et tout ce qui se trouve au-dessus) qui peut être entièrement écrit en C. Généralement, avant de coder le noyau, on développe la couche d'abstraction matérielle (HAL), une interface portable écrite dans le langage du processeur pour chaque processeur. Pour les interruptions, on les gère soit par "interruption" (avec des fonctions de rappel) soit par scrutation (boucles ...). Mais tout ça, c'est implémenté par le HAL. Le noyau peut toujours être entièrement écrit en C.

**loufoque** · 17/02/2009, 18h45

Ca aurait un petit coût de mettre des pointeurs intelligents & compagnie

Pourquoi tu voudrais utiliser des horreurs pareilles ?
Les pointeurs c'est mal, et les pointeurs intelligents ne sont pas mieux...

**poukill** · 17/02/2009, 19h21

Envoyé par loufoque

Pourquoi tu voudrais utiliser des horreurs pareilles ?
Les pointeurs c'est mal, et les pointeurs intelligents ne sont pas mieux...

lol
Ils font parti du RAII il me semble non ?

**amaury pouly** · 18/02/2009, 00h33

Pourquoi tu voudrais utiliser des horreurs pareilles ?
Les pointeurs c'est mal, et les pointeurs intelligents ne sont pas mieux...

Tu peux penser ce que tu veux des pointeurs mais dans un noyau, les pointeurs ce sont tes meilleurs amis... Il n'y a que ça ! Les pointeurs intelligents apportent une sûreté non négligeable dans un gros projet. D'ailleurs il n'y a qu'à regarder du code en C pour voir qu'on passe son temps à gérer les allocations/libération de mémoire et les erreurs. En C++, on peut faire ça plus proprement et se concentrer sur ce que fait le code.

Voilà. C'est bien ce que je voulais soutenir. Et je l'ai déjà d'ailleurs dit, le C utilisé pour écrire un noyau peut rester 100% standard, ce sont les outils à utiliser qu'il faut bien choisir. On ne compile pas un noyau avec n'importe quel compilateur. Il y a des outils spécialisés. J'ai déjà donné des exemples. L'assembleur en ligne n'est pas obligatoire, c'est juste une facilité qu'on aime utiliser (pariel pour la plupart des fonctionnalités non standard généralement utilisées ...). On peut très bien développer toutes les routines dont l'implémentation dépendent d'une plateforme particulière en assembleur et appeler ces routines depuis le C.

Bien sûr. Tout n'est pas écrit entièrement en C. C'est le noyau (et tout ce qui se trouve au-dessus) qui peut être entièrement écrit en C. Généralement, avant de coder le noyau, on développe la couche d'abstraction matérielle (HAL), une interface portable écrite dans le langage du processeur pour chaque processeur. Pour les interruptions, on les gère soit par "interruption" (avec des fonctions de rappel) soit par scrutation (boucles ...). Mais tout ça, c'est implémenté par le HAL. Le noyau peut toujours être entièrement écrit en C.

En général, le HAL fait partie du noyau, c'est *juste* la partie "hardware-dependent" du noyau si l'on peut le dire. Toutefois avec une telle conception du HAL, la quantité de code à écrire n'est pas du tout négligeable et une bonne partie peut être écrite en C (pas très standard pour le coup). La partie à écrire en assembleur peut quand même être réduite au minimum.
Je ne suis par contre pas d'accord avec toi sur le fait que les fonctionnalités listées sont des facilités des compilateurs dont on peut se passer. Pour l'assembleur en ligne je te l'accorde mais le problème de l'alignement n'est pas négligeable par exemple. Même dans le noyau on a besoin, ne serait-ce que pour communiquer avec le matériel.

**NiamorH** · 18/02/2009, 00h48

Envoyé par loufoque

Pourquoi tu voudrais utiliser des horreurs pareilles ?
Les pointeurs c'est mal, et les pointeurs intelligents ne sont pas mieux...

En même temps, on ne peut pas tout mettre sur la pile.

**loufoque** · 18/02/2009, 03h15

Quel rapport ?
Le problème des pointeurs, c'est l'aliasing. La possibilité de référencer la même variable depuis plusieurs parties du code, ce qui rend le programme difficile à comprendre et à analyser.
Pour ces raisons, les pointeurs (ou tout objet se comportant comme eux), c'est à éviter.

Programmer avec des valeurs (éventuellement non copiables), c'est bien mieux, c'est évident. Plus sûr, plus efficace (pas de partage, localité...), déterministe... Ce n'est plus à démontrer.

**Médinoc** · 18/02/2009, 09h51

Mais même un conteneur de valeurs contient des pointeurs, tu sais...
Un vector peut alors être assimilé à un pointeur intelligent sur un tableau, donc selon toi il ne devrait pas être utilisé?

**white_tentacle** · 18/02/2009, 10h08

Mais même un conteneur de valeurs contient des pointeurs, tu sais...

En l'occurrence, certains langages fonctionnels n'ont absolument pas de pointeurs ni d'aliasing.

Je pense notamment à coq, mais on ne fait rien de sérieux en coq. Pour oCaml (pour parler d'un langage avec lequel on fait des choses sérieuses), je ne sais pas.

En fait, il suffit d'avoir des références (certes, une référence est un pointeur déguisé) pour que le problème d'aliasing existe... Et on a besoin de références pour être efficace (copier 100000 éléments, ce n'est pas envisageable).

Le seul embryon d'approche que je vois, dans une approche oo, ce serait de n'avoir que la sémantique de move sur les références (ie la copie d'une référence invalide la référence copiée). Pas sûr que ça règle tous les problèmes, et à peu près sûr que ça en introduit d'autres...

**Trunks** · 18/02/2009, 10h11

Envoyé par loufoque

Pourquoi tu voudrais utiliser des horreurs pareilles ?
Les pointeurs c'est mal, et les pointeurs intelligents ne sont pas mieux...

Perso, ça me choque

Il y a des moments oùon est obligé ou mieux de passer par des pointeurs. Je ne vois pas comment on pourrait se passer, surtout quand on travaille sur du très bas niveau ...

**Goten** · 18/02/2009, 10h21

Ben ce passait des pointeurs pourquoi pas... se passait des smart pointers j'ai plus de mal déjà là...

Enfin dans le cadre d'un noyau je ne saurais dire ..

**Alp** · 18/02/2009, 11h33

@loufoque > dans un noyau, un truc très bas niveau, tu manipules des adresses, tu intéropères avec l'assembleur, tu ne peux pas te permettre de ne bosser que par copie.
Un OS en Haskell ou OCaml ce serait sympa, mais bonjour pour à chaque opération avoir une nouvelle valeur pour le résultat, au lieu d'avoir modifié celle d'entrée. Après, la paresse peut jouer, mais bon pour un noyau je ne sais pas si ça serait indiqué

**HanLee** · 18/02/2009, 11h48

Envoyé par Alp

@loufoque > dans un noyau, un truc très bas niveau, tu manipules des adresses, tu intéropères avec l'assembleur, tu ne peux pas te permettre de ne bosser que par copie.
Un OS en Haskell ou OCaml ce serait sympa, mais bonjour pour à chaque opération avoir une nouvelle valeur pour le résultat, au lieu d'avoir modifié celle d'entrée. Après, la paresse peut jouer, mais bon pour un noyau je ne sais pas si ça serait indiqué

Je pense pas que loufoque voulait dire copier à tout va. Le copy on write, ça fait de la sémantique de valeur sans copie redondante par exemple.

Pour Haskell et OCaml, il faudrait se demander dans quelle mesure leurs avantages de langage fonctionnel et de typage fort sont utiles. Le fait d'avoir une nouvelle valeur ça veut pas dire qu'en interne il n'y ait pas eu modification

.

**Alp** · 18/02/2009, 11h49

Envoyé par HanLee

Je pense pas que loufoque voulait dire copier à tout va. Le copy on write, ça fait de la sémantique de valeur sans copie redondante par exemple.

Dans ce cas, ça irait mieux effectivement.

Envoyé par HanLee

Pour Haskell et OCaml, il faudrait se demander dans quelle mesure leurs avantages de langage fonctionnel et de typage fort sont utiles. Le fait d'avoir une nouvelle valeur ça veut pas dire qu'en interne il n'y ait pas eu modification

.

D'un côté ça éviterait l'effet Windows (

), d'un autre si on reste en purement fonctionnel, ça demanderait de la mémoire

**Médinoc** · 18/02/2009, 12h18

Envoyé par HanLee

Je pense pas que loufoque voulait dire copier à tout va. Le copy on write, ça fait de la sémantique de valeur sans copie redondante par exemple.

Mais ça se manipule typiquement par référence (cachée), souvent comptée, donc pointeurs intelligents...

**HanLee** · 18/02/2009, 13h07

Envoyé par Médinoc

Mais ça se manipule typiquement par référence (cachée), souvent comptée, donc pointeurs intelligents...

Oui mais ce qui compte c'est la sémantique, donc le point de vue de l'utilisateur. L'objet final se comporte comme une valeur pure.

Avec un pointeur intelligent, ça reste une sémantique de référence.

**loufoque** · 18/02/2009, 16h08

Le copy-on-write, c'est uniquement utile si tu copies beaucoup ta valeur sans en avoir réellement besoin.

La meilleure solution, c'est que si bien entendu tu n'as pas besoin de copier ta valeur, de ne pas la copier.
Les sémantiques de mouvement aident pas mal pour ça. Sans sémantique de mouvement, effectivement, mieux vaut opter pour du copy-on-write.

Mais même un conteneur de valeurs contient des pointeurs, tu sais...
Un vector peut alors être assimilé à un pointeur intelligent sur un tableau, donc selon toi il ne devrait pas être utilisé?

Un vecteur ça a une sémantique de valeur, pas de référence.
Que ça utilise des pointeurs on s'en fout.

T a;
T b = a;
a.mutate(); // avec une opération de mutation à définir, qui dépend de ce que symbolise la valeur T

=> b non modifié, sémantique valeur
=> b modifié, sémantique référence

On remarquera que si T est immutable, ça n'a pas de sens de parler de ces sémantiques-là. Le partage comme la copie sont équivalents dans ce cas.