Теорія операційної системи

:: Меню ::

Головна
Представлення даних в обчислювальних системах
Машинні мови
Завантаження програм
Управління оперативною пам'яттю
Сегментна і сторінкова віртуальна пам'ять
Комп'ютер і зовнішні події
Паралелізм з точки зору програміста
Реалізація багатозадачності на однопроцесорних комп'ютерах  
Зовнішні пристрої
Драйвери зовнішніх пристроїв
Файлові системи
Безпека
Огляд архітектури сучасних ОС

:: Друзі ::

Карта сайту
 

:: Статистика ::

 

 

 

 

 

Автоконфігурація

 

— У моєму полі зору з'являється новий об'єкт.
Можливо, ти шафа?
— Немає
— Можливо ти стіл?
— Немає
— Який твій номер?
— Жіночий
— Йду на ви
— Йди
Б. Гребенщиков

Автоматичне визначення встановлених в системі пристроїв і їх конфігурації економить час і сили адміністратора при установці і перенастроюванні ОС. Розробникові ОС, втім, не слід повністю покладатися на автоконфігурацію, особливо при широкому спектрі устаткування, підтримуваного системою: помилки бувають не лише в програмному забезпеченні, але і в апаратних пристроях, у тому числі і в тій частині логіки контроллера, яка забезпечує його ідентифікацію і автонастроювання.
Автонастроювання можливе лише при певній підтримці з боку апаратури. Така підтримка може забезпечуватися декількома способами.

  • Кожен пристрій має фіксовані адреси регістрів. Системна шина або генерує виключення по відсутності пристрою, що адресується, або при читанні з неіснуючої адреси повертає фіксоване значення (частіше всього 0 або OXFFFFFFFF). У другому випадку досить, щоб один з регістрів пристрою після включення живлення обов'язково містив значення, що відрізняється від цього фіксованого. Функція probe драйвера звертається до регістрів цього пристрою, і, прочитавши правильне значення і не отримавши при цьому помилки шини, може зробити вивід, що пристрій присутній. Пристрої, в яких немає драйверів, в такий спосіб не можуть бути виявлені, але ОС все одно не зможе з ними працювати. Цей метод поганий тим, що важко застосуємо при великому числі виготівників периферійних пристроїв і широкій номенклатурі цих пристроїв — конфлікти між адресами пристроїв різних виготівників практично неминучі.
  • Кожен пристрій має ПЗП, який географічно відображується на адреси системної шини. Після запуску завантажувальний монітор сканує всі можливі адреси таких ПЗП і виконує код, що зберігається в знайдених мікросхемах. Цей код реєструє пристрій в конфігураційній базі даних завантажувального монітора. ОС після завантаження звертається до цієї бази. Даний метод поганий тим, що застосуємо, лише якщо пристрої підключаються до систем з бінарно сумісними центральними процесорами.
  • Кожен пристрій містить набір конфігураційних регістрів, обк але також що адресуються географічно. Ці регістри містять той або інший унікальний ідентифікатор пристрою і, можливо, відомості про конфігурацію. Сканування цих регістрів може здійснюватися як самою системою, так і завантажувальним монітором. Цей метод позбавлений татков два попередніх і широко застосовується в більшості сучасних периферійних шин, наприклад в PCI.

Приведені міркування справедливі не лише для пристроїв, що мають адреси на системній шині, але і для пристроїв, що підключаються до шин власною адресацією, наприклад SCSI. Кількість адрес шини SCSI невелика, тому підсистема автоконфігурації швидко може просканувати їх всіх. Кожен пристрій SCSI повинен підтримувати команду INQUIRY як відповідь на яку зобов'язано повернути типа пристрою і іншу інформацію, зокрема, назву виготівника і моделі, підтримувану версію протоколу SCSI і ін. Одна з форм команди INQUIRY дозволяє також перевірити, чи підтримує пристрій яку-небудь іншу команду з набору команд SCSI.
Одна з серйозних неприємностей, яка може виникнути при автоконфігурації, — це конфлікт пристроїв по яких-небудь ресурсах, найчастіше — адресам всіх або деяких регістрів; лінії запиту або вектору переривання. Якщо перший конфлікт вирішуваний лише перенастроюванням апаратури (пристрої з однією і тією ж адресою на шині гарантовано непрацездатні, а в деяких випадках можуть сделать непрацездатною всю шину), то другою може бути обійдений суто програмними засобами.
Дійсно, ніщо не заважає драйверам конфліктуючих пристроїв розділяти один вектор переривання. При прибутку запиту переривання по цьому вектору викликається один з обробників. Він аналізує достаток свого пристрою, і якщо виявляє, що переривання викликане ним, обробляє його. Якщо ж переривання не його, він просто викликає наступний обробник.
Ця схема допускає те, що каскадує потенційно необмеженої кількості обробників, з тим очевидним недоліком, що кожна додаткова ланка ланцюжка значно збільшує затримку переривання для всіх подальших драйверів.
Більшість сучасних ОС використовує складніший механізм обробки переривань, коли пролог і епілог переривання виконуються сервісною функцією, наданої ядром системи, і вже ця функція викликає власне обробник. Протокол обміну зухвалої функції з обробником може включати код повернення: обробник повинен при цьому повідомляти, "його" це переривання або не "його". У останньому випадку необхідно викликати наступний обробник, і так далі.
Ця схема також допускає те, що необмежене каскадує і володіє тим же недоліком, що і попередня, а саме — збільшує затримку для останніх обробників в ланцюжку.
У будь-якому випадку, розділення векторів переривань вимагає активної кооперації з боку обробників цих переривань.


:: Реклама ::

 

:: Посилання ::


 

 

 


Copyright © Kivik, 2017