Специфікація I2O визначає розбивку драйвера пристрою на двох частин: Ос-ос-залежного й апаратно-залежного модуля, створеного для конкретного пристрою. Ці модулі працюють автономно і можуть виконувати задачі незалежно. В даний час підтримка I2O забезпечується в NetWare 4, Windows NT Server 5.0 і UnixWare. Таким чином, технологія з розбивкою драйвера, зменшує загальне число необхідних драйверів: виробники операційних систем пишуть по одному драйвері на кожен клас пристроїв, наприклад дискові контролери, а виробники устаткування - по одному драйвері на кожен свій пристрій, що може бути використаний з будь-якою операційною системою підтримуючий I2O.
Одна з цілей створення відкритої архітектури I2O - забезпечення можливості легкого підключення пристроїв і написання драйверів, що розширює можливості для створення нових систем.
Короткий огляд
Дві частини драйвера I2O пристрою являють собою Operating System Services Module (OSM), модуль обслуговування операційної системи, що забезпечує інтерфейс із нею і Hardware Device Module (HDM), модуль пристрою, що забезпечує керування устаткуванням. OSM працює з зовнішнім пристроєм за допомогою HDM. Спілкування між цими модулями відбувається на двох рівнях - рівні повідомлень, на якому відбувається встановлення зв'язку і транспортному рівні, що визначає способи поділу інформації. Як і в більшості протоколів зв'язку, рівень повідомлень базується на транспортному рівні.
Модель зв'язку I2O, у комбінації із середовищем виконання і конфігураційним інтерфейсом, забезпечує незалежний інтерфейс із HDM. Модулі здатні зв'язатися один з одним без знання архітектури шини або топології системи. Передані повідомлення формують якийсь метаязык, що не залежить від апаратної реалізації. Уся ця технологія сильно нагадує мережу TCP/IP. Така реалізація I2O, крім всього іншого, забезпечує мобільність пристроїв уведення-висновку.
Модель зв'язку I2O
Модель зв'язку для I2O - це система обміну повідомленнями. Коли OSM одержує запит від операційної системи, він транслює його в запит I2O і передає його HDM для обробки. Після обробки запиту, HDM повертає результат назад OSM, посилаючи повідомлення за допомогою рівня повідомлень I2O. Далі результат передається операційній системі, як від будь-якого іншого драйвера пристрою.
Рівень повідомлень
Рівень повідомлень визначає відкритий, стандартний і абстрактний механізм для зв'язку між сервісними модулями, забезпечуючи основу для інтелектуального введення - висновку. Цей рівень, керуючи пересиланням усіх запитів, а також забезпечуючи функціонування API (Application Programming Interface), зв'язує модель драйверів I2O.
Рівень повідомлень складається з трьох основних компонентів: дескриптора повідомлення, сервісної програми повідомлення (Message Service Routine - MSR), і черги повідомлень. Дескриптор власне кажучи є адресою ресурсу, до якого йде звертання. Для кожного повідомлення, що проходить на рівні повідомлень створюється свій дескриптор. Черга повідомлень організується між передавальним і приймальням пристроями.
Коли драйвер формує повідомлення, воно міститься в чергу і для його обробки активізується MSR. Повідомлення містить двох частин - заголовок і тіло. Заголовок містить тип повідомлення й адреса його відправника.
I2O базується на черзі між MSR і відправником. Ініціатор запиту і сервісний модуль обслуговуються IOP. I2O визначає також формат пам'яті, необхідної для функціонування технології, що не залежить від організації операційної системи.
Модуль обслуговування операційної системи - OSM
OSM забезпечує інтерфейс між операційною системою і рівнем повідомлень I2O. У використовуваній моделі драйверів, OSM являє собою ту частину драйвера, що забезпечує інтерфейс між системно-залежним API і абстрактним форматом повідомлень, що посилаються в HDM для обробки. OSM залежать від операційних систем і створюються їх розроблювачами.
OSM переводить повідомлення операційної системи у формат, що може бути зрозумілий HDM. Передача інформації назад, від HDM до операційної системи реалізується також через OSM за допомогою рівня повідомлень I2O.
Один OSM може обслуговувати множинні HDM. Завдяки існуванню дескрипторів на рівні повідомлень, OSM має можливість розсилати свої повідомлення багатьом адресатам, а також організовувати пересилання інформації між ними.
Апаратний модуль пристрою - HDM
HDM - низкорівневий модуль у середовищі I2O. HDM являє собою аппартнозалежну частину драйвера, що забезпечує взаємодія з контролером або безпосередньо пристроєм. Можна провести аналогію між HDM і апаратно залежною частиною драйвера мережі або драйвером SCSI у тім виді, у якому він існує сьогодні. Кожен HDM унікальний для кожного конкретного пристрою і виробника. Він підтримує всі низько-рівневі операції пристрою, такі як синхронні й асинхронні запити, а також транзакції керовані подіями.
HDM оточений середовищем I2O, що ізолює його від спілкування з операційною системою і шинними протоколами. Таким чином, один HDM може бути використаний не тільки з різними операційними системами, але навіть з різними платформами. HDM пишеться виробником пристрою і звичайно прошивається в адаптер.
Системне середовище
Модель I2O може бути застосована в будь-яких умовах - як і в одно процесорних, так і багатопроцесорних системах.
Інтерфейси OSM і HDM входять в основний API I2O. Середовище виконання OSM залежать від операційної системи, що впливає на реалізацію деяких функцій API. У задачі OSM входить реалізація зв'язку між API, використовуваного операційною системою, і HDM, керуючим пристроєм.
Крім основних функцій у API HDM може бути введений додатковий набір команд. Цей набір необхідний для прямого спілкування операційної системи з HDM і застосовується при її завантаженні для ініціалізації ядра. Приблизно це і реалізується в основних багатозадачних середовищах. Однак цей додатковий набір також є єдиним для всіх пристроїв одного класу. Так що технологія I2O не несе в собі ніяких обмежень для області її використання.
Реалізація архітектури I2O
Гнучка, відкрита архітектура I2O надає розроблювачам різні варіанти для реалізації. Основні три підходи наступні:
· Установка IOP на материнську плату. IOP установлюється на материнську плату і використовується при інтелектуальному введенні-висновку. У цьому випадку IOP використовується в якості стандартного PCI Bridge і додає "інтелектуальності" до шини PCI
· Установка IOP на додатковій платі розширення. Інтелектуальний контролер I2O інсталюється як, наприклад, звичайна мережна карта
· Установка опціональної плати розширення з IOP у спеціалізований слот на материнській платі. Цей процесор буде функціонувати з усіма пристроями, що вимагають інтелектуальний уведення-висновок
Практика використання I2O
Пристрою, сумісні з технологією I2O будуть маркіруватися виробниками як "I2O ready". Однак в одній системі можна буде застосовувати, як і I2O пристрою, так і звичайні, не інтелектуальні пристрої. Це дозволить організувати легкий перехід до нової архітектури. Тим більше вартість материнської плати з IOP зросте максимум на $10-15.
Очікується, що в зв'язку з уведенням додаткових пристроїв (IOP) і розбивки драйвера на частини, швидкість обміну інформацією може упасти. У принципі, ця думка виправдана. Однак, у зв'язку з тим що по-перше спрощується задача написання драйверів, а по-друге розвантажується центральний процесор, загальна ефективність системи повинна зрости. Приклад подібного росту ефективності - застосування IDE Bus Master драйверів.
Упровадження технології інтелектуального введення-висновку повинне відбутися найближчим часом, тим більше що ведучі виробники материнських плат уже представили свої вироби з установленим на борті IOP i960, єдиним на дійсний час процесором для реалізації I2O. Перший час I2O буде використовуватися в серверах, однак у найближчому майбутньому може поширитися і на домашні системи.
Висновок
Таким чином, I2O пропонує новий підхід до організації інтелектуального введення-висновку, спрощуючи життя, як розроблювачем пристроїв, так і виробникам операційних систем завдяки поділові функцій драйверів. Крім того, I2O покликана реалізувати нову високопродуктивну концепцію високопродуктивного і платформено-незалежного інтелектуального введення-висновку. Відкритість цього стандарту дозволяє легко перейти від сьогоднішніх реалій у світ інтелектуального обміну інформацією.
[1] Контакт В8 по-разному использовался в ХТ и АТ. Для обеспечения совместимости IBM XT со специфической системой под названием 3270 РС, восьмой (ближайший к блоку питания) слот расширения ХТ был особенным. В него можно было устанавливать лишь платы, выдающие на контакт В8 сигнал "выбор платы" или, как его еще называют, "сигнал J8" - например, плату клавиатуры/таймера от 3270 РС. К этим платам, кроме того, предъявлялись другие требования по синхронизации. В IBM AT такую хитрую совместимость обеспечивать не стали, а контакт В8 приспособили для подачи сигнала NOWS - No Wait State