Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 3 sur 3
  1. #1
    Invité de passage
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2012
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : décembre 2012
    Messages : 2
    Points : 1
    Points
    1

    Par défaut Faut-il des drivers pour utiliser des périphériques en mode protégé ?

    Bonjour à tous, il me semble avoir lu que en mode protégé il fallait des drivers pour utiliser les périphériques alors qu'ils n'étaient pas nécessaires en mode réel : déjà est-ce que cela est vrai ? Ensuite est-ce que quelqu'un peut m'éclairer un petit peu s'il vous plaît

  2. #2
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Chercheur d'emploi
    Inscrit en
    septembre 2007
    Messages
    5 455
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur d'emploi
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2007
    Messages : 5 455
    Points : 13 919
    Points
    13 919

    Par défaut

    Bonjour et bienvenue,

    En fait non : techniquement, les périphériques eux-mêmes vont être exploités de la même façon, au travers des ports I/O et/ou de zones de mémoire mappées dans le plan adressable.

    Par contre, en mode réel, par définition, il n'y a aucune restriction d'accès à ces ports ou à ces zones. Rien ne peut empêcher un programme d'y accéder directement.

    De plus, le seul système d'exploitation grand public et tous usages qui ait réellement exploité le mode réel sur PC est D.O.S. Ce système était par nature mono-utilisateur et mono-tâche. Cependant, il était très répandu et et il était naturel pour pratiquement tout le monde de travailler avec, comme aujourd'hui le gens le font sous Windows (Linux ou *BSD pour les initiés). Si bien qu'il était tout-à-fait sûr de manipuler directement les ressources de son PC, qui étaient d'ailleurs relativement limitées dans les premiers temps. Par exemple, on pouvait facilement inhiber les interruptions IRQ lorsque le temps d'exécution était un facteur critique. Tout cela pour dire, donc, qu'on pouvait à la fois directement accéder aux ports I/O du matériel et le faire sans risquer d'interférer avec le système ou les autres programmes.

    Évidemment, le système proposait quand même des pilotes et des points d'entrée officiels pour commander les principaux périphériques surtout quand ils étaient installés en standard dans un PC, comme un port parallèle ou un port série. Seulement, ceux-là mêmes étaient tellement rudimentaires qu'il était souvent plus simple — et également beaucoup plus amusant — pour le programmeur d'y accéder directement plutôt qu'utiliser une routine sur laquelle il n'avait aucun contrôle, qui n'était pas spécialement optimisée, et qui introduisait une dépendance dans son programme.

    Avec l'arrivée du mode protégé et, concomitamment, des systèmes d'exploitation s'appuyant dessus, par définition, ton programme ne peut plus écrire en dehors de la zone mémoire qui lui a été allouée ni écrire directement dans les ports d'entrée/sortie. L'idée étant d'empêcher un programme malveillant ou défaillant d'aller mettre le souk dans le reste du système ainsi que gérer le partage de ressource entre les différents logiciels. Exemple, le clavier : tant que tu es tout seul, pas de problème. Par contre, dès lors que deux programmes sont à l'écoute, s'ils lisent simultanément le clavier, chacun d'eux risque de récupérer une touche sur deux ! C'est bien sûr totalement inacceptable. Il faut donc un système superviseur qui soit donc en charge de récupérer d'un côté tout ce qui provient du clavier et, de l'autre côté, de présenter tout cela sous une forme unifiée au système d'exploitation qui, lui, va les mettre à disposition de tous les programmes qui en feront la demande.

    En résumé : c'est à la fois l'interdiction d'accès direct aux périphérique et la mise en place d'un système multitâche qui impose aujourd'hui aux logiciels de passer par de la programmation système, et donc des pilotes.

    Par contre, il n'y a rien d'impossible techniquement. Linux, par exemple, permet aux programmes de demander le droit d'accès à certains port d'entrées-sorties, via les appels ioperm() et iopl(). Libre au système (et à son administrateur par l'entremise de la configuration qu'il lui applique) de refuser ces droits. Mais s'il les accorde, le programme en langage machine gagne à nouveau la possibilité d'aller exploiter lui-même ces ports. Après, au niveau de la gestion du micro-processeur, soit le système laisse une exception se déclencher à chaque fois, la rattrape et honore la commande, soit il fait passer le segment du processus dans un niveau de privilège où il est permis d'accéder aux ports.

  3. #3
    Invité de passage
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2012
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : décembre 2012
    Messages : 2
    Points : 1
    Points
    1

    Par défaut

    Merci beaucoup pour cette réponse très claire ! (Et rapide !)
    Ainsi qu'une bonne année 2013 à tous

+ Répondre à la discussion
Cette discussion est résolue.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •