Réponses:
Toute E / S est gérée par un appel système appelé par un processus. Finalement, un tel appel système se répercutera sur une fonction appropriée de pilote de périphérique de bas niveau pour effectuer l'opération d'E / S réelle.
Les E / S peuvent être délicates - pour obtenir réellement des données dans et hors de l'appareil, diverses étapes peuvent devoir être suivies, dans l'ordre et éventuellement avec des contraintes de temps. Si ces étapes ne sont pas terminées de manière atomique, la prochaine fois qu'elles seront tentées, le périphérique risque de ne pas répondre, de se comporter mal ou même de provoquer le blocage du système. Ces étapes peuvent être différentes et uniques pour chaque périphérique, d'où la raison pour laquelle il existe autant de pilotes de périphériques.
Un pilote de périphérique bien écrit doit savoir comment gérer le périphérique qu'il tente de réparer, il ne devrait donc normalement pas rencontrer de problèmes, sauf en cas de bogue de pilote, si vous utilisez le mauvais pilote pour le périphérique ou si le périphérique physique échoue.
Maintenant que j'ai lu le livre "La conception des systèmes d'exploitation Unix" de Maurice Bach, permettez-moi de répondre à cette question par moi-même.
En bref, rendre les E / S ininterruptibles a pour but de faire terminer la tâche d'E / S DÈS QUE POSSIBLE, sans être gêné par des signaux.
Quelques connaissances connexes que j'ai acquises du livre:
Certains chemins de code dans le noyau sont marqués comme non interruptibles, principalement parce que le code doit respecter un timing strict (pour répondre à un périphérique) ou parce qu'il fait quelque chose qui n'admet pas d'interférence. Dans le cas de Linux, la plupart des premiers ont été poussés vers des bandes de roulement indépendantes du noyau, et les seconds ont été pour la plupart éradiqués (je soupçonne principalement sous la pression des machines multi-CPU actuelles). C'est à dire, cela fait un certain temps maintenant que je n'ai pas vu de processus dans le sommeil ininterrompu.
write(2)
est autorisé à retourner plus tôt, en renvoyant le nombre d'octets réel écrit, qui peut être inférieur à la longueur de tampon passée comme 3e argument.