Drivers de stockage et objets de périphériques

Les noms des partitions
désignées par boot.ini sont sou la forme multi(0)disk(0)rdisk(0)partition(1).

Ces noms sont des noms ARC (Advanced RISC Computing) car ils font partie d’un
schéma standard de noms de partitions que le firmware Alpha et d’autres processeurs
RISC utilisent. NTLDR traduit le nom de la valeur d’initialisation de boot.ini
sélectionnée par l’utilisateur vers la partition d’initialisation appropriée,
puis charge les fichiers système NT (en commençant par le Registre, ntoskrnl.exe
et les pilotes d’initialisation) en mémoire pour continuer le processus de boot.

Durant l’initialisation, le kernel de Windows NT lance les pilotes de stockage
disque. Les pilotes de stockage de Windows NT respectent une architecture classe/port/miniport,
dans laquelle Microsoft fournit un pilote de classe qui met en oeuvre les fonctionnalités
communes à  tous les systèmes de stockage et un pilote de port qui met en oeuvre
les fonctionnalités commune à  un bus particulier (par exemple SCSI ou IDE). Les
OEM fournissent les pilotes miniport qui s’intègrent aux pilotes de port pour
interfacer NT à  une implémentation particulière.

Par exemple, Adaptec fournit des pilotes miniport SCSI pour ses divers contrôleurs
SCSI. L’intérêt de cette répartition est double. Un développeur de miniport travaille
pour l’environnement miniport, moins complexe que l’environnement des pilotes
NT.

D’autre part, Microsoft fournit des pilotes de classes et de ports pour Windows
9x, ce qui fait que les pilotes miniport que les développeurs écrivent pour NT
tournent sous Windows 9x et réciproquement.Lorsque les drivers miniport présentent
les disques qu’ils identifient plus avant lors de l’initialisation au pilote de
classe, le Gestionnaire d’entrées/sorties de Windows NT inclut la fonction IoReadPartitionTable
que le pilote de classe invoque pour chaque disque. IoReadPartitionTable invoque
alors les entrées/sorties de disques au niveau secteur (fournis par les drivers
de classes, de port et de miniport), pour lire la table de partitions d’un disque
et construire une représentation interne du partitionnement du disque.
Le pilote de classes de disque crée des  » device objects  » ou objets de périphériques
pour représenter chaque partition primaire (y compris pour les partitions primaires
dans une partition étendue) que le pilote obtient de IoReadPartitionTable. Les
pilotes de périphériques utilisent les objets de périphériques pour représenter
à  la fois les unités physiques et logiques, notamment les disques, les claviers
et les interfaces de gestion des pilotes.
Les pilotes de périphériques peuvent nommer un objet de périphérique de telle
sorte que d’autres pilotes de périphériques ou applications peuvent ouvrir l’objet
et lui envoyer des requêtes d’entrée/sortie. Le pilote de classes de disques crée
un répertoire HarddiskX (X étant le numéro de disque attribué par NT au disque)
dans l’espace de noms du gestionnaire d’objets de NT pour chaque disque dur. Le
pilote de classes de disques place ensuite les objets de périphériques de la partition
dans le répertoire HarddiskX du disque sur lequel résident les objets.

Par exemple, l’écran 1 montre le contenu du répertoire \device\harddisk0 d’un
ordinateur dont le disque dur primaire a quatre partitions, représentées par les
quatre objets de partitions numérotées représentées dans le panneau de droite.
Le pilote de classe de disque donne le nom partition0 à  l’objet de périphérique
qui représente la totalité du disque physique.
Lorsqu’un driver de périphérique ou une application envoie une requête d’entrée/sortie
à  un objet de périphérique, le gestionnaire des E/S de NT route la requête (arrivée
dans un paquet IRP – I/O Request Packet) vers le pilote de périphérique qui a
créé l’objet de périphérique ciblé. Ainsi, si une application veut lire le secteur
d’initialisation de la seconde partition de Harddisk0, elle doit d’abord ouvrir
l’objet de périphérique \device\harddisk0\partition2, puis envoyer une requête
à  l’objet pour lire 512 octets, en commençant à  la piste 0 de l’unité.
Le gestionnaire d’E/S de Windows NT route la requête de l’application vers le
pilote de classe de disque, signalant à  ce dernier que l’IRP est destiné à  l’objet
de périphérique de la partition 2. Les partitions étant des conventions logiques
utilisées par l’OS pour représenter des zones contiguà«s sur un disque physique,
le pilote de classe doit traduire les décalages propres à  une partition par rapport
à  la piste 0 du disque. Si la partition 2 commence au secteur 4096 du disque,
le pilote de classe ajuste les paramètres de l’IRP pour prendre en compte ce décalage
avant de transmettre la requête au pilote de miniport.
Ce dernier se charge des E/S physiques sur disque et lit les données requises
dans un buffer d’application désigné dans l’IRP.

Une fois que le Gestionnaire d’entrées a initialisé les pilotes de stockage disque,
il invoque la fonction interne de IoAssignDriveLetters
L’API Wind32 ne connaît pas l’espace de noms du Gestionnaire d’objets de Windows
NT. L’OS réserve deux sous répertoires d’espaces de noms différents pour Win32
et nomme une d’entre-elles \??. Dans ce sous-répertoire, NT rend disponible des
objets de périphériques avec lesquels les applications Win32 interagissent – y
compris les ports COM et parallèles.
Parce que les objets de disques résident en réalité dans d’autres sous-répertoires,
Windows NT utilise des liens symboliques pour associer les noms dans le répertoire
\?? avec des objets situés autre part dans l’espace de noms. Pour chaque disque
physique d’un système, le Gestionnaire d’E/S crée un lien \??\PhysicalDriveX qui
pointe sur \device\harddisk\Partition0.
Les applications Win32 qui interagissent directement avec les secteurs d’un disque,
ouvrent le disque en spécifiant le nom \\.\PhysicalDriveX (X étant le numéro de
l’unité) pour invoquer l’API Win32 CreateFile. La couche d’application Win32 convertit
le nom à  \??\PhysicalDriveX avant de communiquer le nom au Gestionnaire d’objets
de Windows NT.