Quand nous parlons d'une fonction, nous écrivons:
"nom_de_function [ fichier emplacement . extension ]"
Par exemple:
"schedule [kernel/sched.c]"
nous dit que nous parlons de
"schedule"
function accessible depuis le fichier
[ kernel/sched.c ]
Note: Nous supposons /usr/src/linux comme racine du dossier.
L'indentation du code source est de 3 caractères blancs.
Nous utilisons l'analyse d'"InterCallings" (ICA) pour voir (de manière indentée) comment les fonctions du noyau s'appellent les unes les autres.
Par exemple, la commande de sleep_on est décrite ainsi dans ICA:
|sleep_on |init_waitqueue_entry -- |__add_wait_queue | enqueuing request |list_add | |__list_add -- |schedule --- waiting for request to be executed |__remove_wait_queue -- |list_del | dequeuing request |__list_del -- sleep_on ICA
L'ICA indenté est suivi par les fonctions d'emplacement:
Note: Nous n'indiquons plus l'emplacement du dossier, s'il est indiqué juste avant.
Dans un ICA une telle ligne ressemble à ce qui suit
function1 -> function2
signifie que < function1 > est un pointeur générique vers une autre fonction. Dans ce cas < function1 > pointe vers < function2 >.
Quand nous écrivons:
function:
ça signifie que < fonction > n'est pas une vraie fonction. C'est une étiquette/un label (typiquement étiquette/label d'assembleur).
Dans beaucoup de sections nous pouvons reporter un code ''C'' ou un ''pseudo-code''. Dans de vrais fichiers source, vous pourriez utiliser code ''assembleur'' ou ''non structuré de ''. Cette différence est à but d'étude.
Les avantages d'utiliser ICA (Analyse d'InterCallings) sont nombreux:
Comme tous les modèles théoriques, nous simplifions la réalité évitant beaucoup de détails, comme le vrai code source et les conditions spéciales.