le noyau ne chargeait pas forcément tout le binaire
Oui, il mappe les pages à la demande.
Et lors d'une faute de page le noyau pouvait récupérer la partie du binaire manquant et la charger en RAM. c'est pourquoi le noyau verrouille les binaires.
Ça n'est pas un « verrouillage » au sens filesystem du terme : il a une référence vers un inode dans le VFS qui sera toujours le même même si le fichier est remplacé ; ainsi, un « écrasement » lors d'une mise à jour ne le perturbera pas. Mais note que niveau VFS, c'est un unlink + creat (ou rename), donc un fichier différent qui est créé à sa place. Le fichier binaire original restera inchangé. On pourrait modifier l'exécutable « en live » également, le noyau ne l'interdit pas, si tu as encore une référence au descripteur du fichier mappé : ça ferait effectivement des trucs bizarre, bien qu'il faille également correctement jouer de l'invalidation du cache d'instruction pour obtenir un truc maîtrisé.
[^] # Re: Cela ne se passe pas bien
Posté par benoar . En réponse au message que ce passe t'il quand on fait des mises à jour sur un programme qui en cours d'exécution. Évalué à 2. Dernière modification le 13 avril 2019 à 00:04.
Oui, il mappe les pages à la demande.
Ça n'est pas un « verrouillage » au sens filesystem du terme : il a une référence vers un inode dans le VFS qui sera toujours le même même si le fichier est remplacé ; ainsi, un « écrasement » lors d'une mise à jour ne le perturbera pas. Mais note que niveau VFS, c'est un unlink + creat (ou rename), donc un fichier différent qui est créé à sa place. Le fichier binaire original restera inchangé. On pourrait modifier l'exécutable « en live » également, le noyau ne l'interdit pas, si tu as encore une référence au descripteur du fichier mappé : ça ferait effectivement des trucs bizarre, bien qu'il faille également correctement jouer de l'invalidation du cache d'instruction pour obtenir un truc maîtrisé.