49448 (751231), страница 6

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 6)

I₂O базується на черзі між MSR і відправником. Ініціатор запиту і сервісний модуль обслуговуються IOP. I₂O визначає також формат пам'яті, необхідної для функціонування технології, що не залежить від організації операційної системи.

Модуль обслуговування операційної системи - OSM

OSM забезпечує інтерфейс між операційною системою і рівнем повідомлень I₂O. У використовуваній моделі драйверів, OSM являє собою ту частину драйвера, що забезпечує інтерфейс між системно-залежним API і абстрактним форматом повідомлень, що посилаються в HDM для обробки. OSM залежать від операційних систем і створюються їх розроблювачами.

OSM переводить повідомлення операційної системи у формат, що може бути зрозумілий HDM. Передача інформації назад, від HDM до операційної системи реалізується також через OSM за допомогою рівня повідомлень I₂O.

Один OSM може обслуговувати множинні HDM. Завдяки існуванню дескрипторів на рівні повідомлень, OSM має можливість розсилати свої повідомлення багатьом адресатам, а також організовувати пересилання інформації між ними.

Апаратний модуль пристрою - HDM

HDM - низкорівневий модуль у середовищі I₂O. HDM являє собою аппартнозалежну частину драйвера, що забезпечує взаємодія з контролером або безпосередньо пристроєм. Можна провести аналогію між HDM і апаратно залежною частиною драйвера мережі або драйвером SCSI у тім виді, у якому він існує сьогодні. Кожен HDM унікальний для кожного конкретного пристрою і виробника. Він підтримує всі низько-рівневі операції пристрою, такі як синхронні й асинхронні запити, а також транзакції керовані подіями.

HDM оточений середовищем I₂O, що ізолює його від спілкування з операційною системою і шинними протоколами. Таким чином, один HDM може бути використаний не тільки з різними операційними системами, але навіть з різними платформами. HDM пишеться виробником пристрою і звичайно прошивається в адаптер.

Системне середовище

Модель I₂O може бути застосована в будь-яких умовах - як і в одно процесорних, так і багатопроцесорних системах.

Інтерфейси OSM і HDM входять в основний API I₂O. Середовище виконання OSM залежать від операційної системи, що впливає на реалізацію деяких функцій API. У задачі OSM входить реалізація зв'язку між API, використовуваного операційною системою, і HDM, керуючим пристроєм.

Крім основних функцій у API HDM може бути введений додатковий набір команд. Цей набір необхідний для прямого спілкування операційної системи з HDM і застосовується при її завантаженні для ініціалізації ядра. Приблизно це і реалізується в основних багатозадачних середовищах. Однак цей додатковий набір також є єдиним для всіх пристроїв одного класу. Так що технологія I₂O не несе в собі ніяких обмежень для області її використання.

Реалізація архітектури I₂O

Гнучка, відкрита архітектура I₂O надає розроблювачам різні варіанти для реалізації. Основні три підходи наступні:

• Установка IOP на материнську плату. IOP установлюється на материнську плату і використовується при інтелектуальному введенні-висновку. У цьому випадку IOP використовується в якості стандартного PCI Bridge і додає "інтелектуальності" до шини PCI

• Установка IOP на додатковій платі розширення. Інтелектуальний контролер I₂O інсталюється як, наприклад, звичайна мережна карта

• Установка опціональної плати розширення з IOP у спеціалізований слот на материнській платі. Цей процесор буде функціонувати з усіма пристроями, що вимагають інтелектуальний уведення-висновок

Практика використання I₂O

Пристрою, сумісні з технологією I₂O будуть маркіруватися виробниками як "I₂O ready". Однак в одній системі можна буде застосовувати, як і I₂O пристрою, так і звичайні, не інтелектуальні пристрої. Це дозволить організувати легкий перехід до нової архітектури. Тим більше вартість материнської плати з IOP зросте максимум на $10-15.

Очікується, що в зв'язку з уведенням додаткових пристроїв (IOP) і розбивки драйвера на частини, швидкість обміну інформацією може упасти. У принципі, ця думка виправдана. Однак, у зв'язку з тим що по-перше спрощується задача написання драйверів, а по-друге розвантажується центральний процесор, загальна ефективність системи повинна зрости. Приклад подібного росту ефективності - застосування IDE Bus Master драйверів.

Упровадження технології інтелектуального введення-висновку повинне відбутися найближчим часом, тим більше що ведучі виробники материнських плат уже представили свої вироби з установленим на борті IOP i960, єдиним на дійсний час процесором для реалізації I₂O. Перший час I₂O буде використовуватися в серверах, однак у найближчому майбутньому може поширитися і на домашні системи.

Висновок

Таким чином, I₂O пропонує новий підхід до організації інтелектуального введення-висновку, спрощуючи життя, як розроблювачем пристроїв, так і виробникам операційних систем завдяки поділові функцій драйверів. Крім того, I₂O покликана реалізувати нову високопродуктивну концепцію високопродуктивного і платформено-незалежного інтелектуального введення-висновку. Відкритість цього стандарту дозволяє легко перейти від сьогоднішніх реалій у світ інтелектуального обміну інформацією.

1 Контакт В8 по-разному использовался в ХТ и АТ. Для обеспечения совместимости IBM XT со специфической системой под названием 3270 РС, восьмой (ближайший к блоку питания) слот расширения ХТ был особенным. В него можно было устанавливать лишь платы, выдающие на контакт В8 сигнал "выбор платы" или, как его еще называют, "сигнал J8" - например, плату клавиатуры/таймера от 3270 РС. К этим платам, кроме того, предъявлялись другие требования по синхронизации. В IBM AT такую хитрую совместимость обеспечивать не стали, а контакт В8 приспособили для подачи сигнала NOWS - No Wait State

Характеристики

Список файлов доклада