Обзор массового хранения
Термин массовое хранение охватывает широкий диапазон устройств. Широко определенный, устройство массового хранения является любым устройством хранения, которое имеет носители, локальные для машины, и может поддерживать файловую систему. OS X поддерживает устройства массового хранения со штабелем драйверов, управляющих физическим соединением устройства к шине, переводу команд с системы на устройство и разделам устройства, которые видит пользователь.
В этой главе описываются конструкцию и реализацию штабеля драйвера массового хранения. Это также описывает семью Model архитектуры SCSI, реализующую спецификации Модели архитектуры SCSI в транспортном уровне драйвера и Семействе систем хранения, поддерживающем уровень услуг устройства.
Устройства массового хранения в OS X
Штабель драйвера массового хранения OS X представляет абсолютно различную модель поддержки устройства массового хранения со стороны этого в более ранних версиях Mac OS. Вместо уникального драйвера для каждого устройства массового хранения, штабель драйвера массового хранения OS X разделяет коммуникацию устройства на различные уровни, включающие отдельные драйверы. Предоставленные Apple драйверы предоставляют услуги, такие как обработка событий и заменяющий поддержку в горячем режиме, позволяя Вам записать драйвер, поддерживающий только различную или дополнительную функциональность, которой требует Ваше устройство.
В OS X драйверы устройства массового хранения ATA не полностью участвуют в штабеле драйвера массового хранения. Драйвер для устройства массового хранения ATA существует в отдельном штабеле, обеспечивая ту же функциональность как драйверы на нижних уровнях штабеля драйвера массового хранения. Это действительно связывается с уровнем услуг устройства, однако, через интерфейс, который это обеспечивает.
Штабель драйвера массового хранения в версии 10.1 OS X и более поздних поддержках устройства SCSI периферийного устройства вводит 00$, 05$, 07$ и 0$ E. Это включает устройства, такие как CDROM и диски DVD-ROM, карты флэш-памяти и магнитооптические устройства. В более поздних версиях OS X, однако, штабель массового хранения будет включать поддержку других периферийных устройств SCSI, таких как сканеры. До тех пор отдельные драйверы вне штабеля драйвера массового хранения продолжают предоставлять поддержку для этих устройств.
Традиционно, термин «SCSI» упомянул исходную параллельную шину, определенную Моделью 1 архитектуры SCSI и спецификациями Модели 2 архитектуры SCSI. С введением Волоконно-оптического канала и Serial Storage Architecture (SSA), однако, спецификация Модели 3 архитектуры SCSI развернула срок для определения архитектуры, обрабатывающей непротиворечивым способом устройства, придерживающиеся спецификаций Модели архитектуры SCSI, независимых от физической шины, к которой присоединено устройство.
В этом документе термин «SCSI» относится к любой физической шине (FireWire, ATAPI, параллельный SCSI или USB) или устройство, соответствующее спецификациям Модели 2 архитектуры SCSI. Этот документ относится к исходной технологии параллельной шины SCSI как SCSI Parallel Interconnect (SPI) или параллельный SCSI.
Драйверы массового хранения
В версиях Mac OS перед OS X массовое хранение запросы I/O обслуживались монолитным драйвером устройства, который был ответственен за каждую схему выделения разделов, набор команд и протокол шины, связанный с его устройством. Было взаимно-однозначное соответствие между драйверами и устройствами: новое устройство потребовало нового драйвера, независимо от того насколько подобный новый драйвер мог бы быть к существующему ранее. С введением OS X, однако, эта модель драйвера устройства была заменена Набором I/O, объектно-ориентированным модульным принципом подчеркивания платформы разработки драйвера и возможностью многократного использования.
В OS X драйвер для устройства массового хранения, которое монтирует файловую систему или является загрузочным, является расширением ядра или KEXT. Этот KEXT наследовал большую часть своей функциональности от семьи I/O Kit, реализующей абстракции программного обеспечения, характерные для всех устройств определенного типа.
В OS X единственный драйвер устройства массового хранения больше не поэтому ответственен за информацию о разделе, протоколы шины или блочные средства управления параметром, потому что эти подробные данные обрабатываются другими объектами в штабеле драйвера массового хранения. Кроме того, сложности, представленные функциями OS X, такими как его многопоточное ядро и заменяющий поддержку в горячем режиме, обрабатываются кодом семейства, освобождая драйвер для поддержки функций, уникальных для его типа устройства или типа устройства.
Понятие Набора I/O семьи служит совершенной основой для реализации Модели архитектуры SCSI промышленного стандарта. Спецификации Модели архитектуры SCSI (http://t10 .org) обеспечивают инструкции для реализации системы через все межсоединение SCSI и среды протокола. Спецификации Модели архитектуры SCSI никоим образом не ограничиваются, чтобы быть параллельными одним только устройствам SCSI. Превышая аппаратные средства SCSI, Модель архитектуры SCSI определяет функциональное разбиение наборов команд SCSI и стандартов протокола для устройств, понимающих блоки дескриптора команды и придерживающихся спецификаций Модели архитектуры SCSI, независимо от физической шины, к которой они присоединены.
Семья Model архитектуры SCSI (описанный в семье Модели архитектуры SCSI) реализует спецификации Модели архитектуры SCSI в абстракциях кода, предоставляющих поддержку для широкого диапазона устройств через различные шины. Семейство систем хранения (описанный в Семействе систем хранения) обеспечивает APIs что доступ к поддержке к пространству памяти, представленному устройствами, независимыми от базовой технологии, вовлеченной в транспорт данных.
Штабель Драйвера Массового хранения дает обзор штабеля драйвера массового хранения, концентрирующегося на архитектуре штабеля и представляющего взаимодействие его уровней. Несмотря на то, что важно помнить, что объекты, населяющие эти уровни, наследовались от базовых классов Набора I/O и разделяют функциональность, предоставленную семьями I/O Kit, одинаково важно избежать путать архитектуру штабеля драйвера с «архитектурой» иерархии классов. Для подчеркивания различия между логической укладкой драйверов массового хранения и иерархией классов Набора I/O тех драйверов реализация Набора I/O штабеля драйвера описана отдельно в Объектах Драйвера Массового хранения.
Штабель драйвера массового хранения
Штабель драйвера массового хранения состоит из трех фундаментальных уровней, показанных на рисунке 1-1. Штабель ориентирован с физическим устройством в нижней части и окончательном клиенте того устройства (приложение или система) наверху.
Наверху числа, выше уровня услуг устройства, граница пользовательского ядра. Приложения находятся выше этой границы вместе с основанными на приложении драйверами, как те для сканеров, лентопротяжных устройств и цифровых фотоаппаратов.
На стороне ядра границы верхний слой штабеля массового хранения, уровня услуг устройства. Этот уровень содержит универсальный драйвер блочной системы хранения и дополнительные схемы фильтра, которые могут реализовать шифрование или проверку.
Универсальный драйвер блочной системы хранения просматривает устройство массового хранения как просто пространство памяти без знания наборов команды устройства или физических протоколов обмена. Схемы фильтра просматривают устройства массового хранения еще более абстрактно: Устройства массового хранения могут содержать мультимедийные объекты, которые могут представлять любое подмножество устройства, такого как раздел диска, или даже ряд многократных устройств, таких как дисковый контроллер RAID, использующий несколько дисков вместе для появления как единственный объем.
Маловероятно, что необходимо будет разделить универсальный драйвер блочной системы хранения на подклассы для поддержки особенностей определенного устройства. Намного лучшее решение состоит в том, чтобы разделить на подклассы логическую единицу или драйвер служб протокола в транспортном уровне драйвера. Создание драйвера схемы фильтра, однако, является хорошим способом предоставить поддержку для дополнительного манипулирования данными, которого может потребовать Ваше устройство. Уровень Услуг устройства описывает этот уровень более подробно.
Средний уровень штабеля массового хранения является транспортным уровнем драйвера. Этот уровень включает информацию о связи с определенными типами устройств. Запросы I/O от уровня услуг устройства входят в транспортный уровень драйвера, где они переводятся в команды, подходящие для целевого устройства, и затем отправили через надлежащую шину в физическом взаимосвязанном уровне. Драйверы логической единицы и драйверы служб протокола, от которых можно разделить специфичные для устройства и специфичные для шины драйверы на подклассы, находятся в этом уровне. Сам транспортный уровень драйвера является многослойным и является фокусом Транспортного Уровня Драйвера.
Уровень выше устройства является физическим взаимосвязанным уровнем. Как его имя предполагает, этот уровень состоит из набора объектов, связанных с соединением устройства к шине. Драйверы контроллера шины для FireWire, USB и ATAPI здесь, вместе с объектами, представляющими устройство и, в некоторых случаях, логические части устройства.
Если нет связанные с шиной проблемы, необходимо адресоваться для устройства, маловероятно, что необходимо будет разделить любой физический взаимосвязанный драйвер на подклассы.
Транспортный уровень драйвера
Транспортный уровень драйвера преобразовывает универсальные запросы I/O в специфичные для устройства команды, подходящие для транспорта на определенной шине. Этот уровень (показанный на рисунке 1-2) состоит из ссылки к уровню услуг устройства и двум основным подуровням, выполняющим перевод запросов I/O.
Между уровнем услуг устройства и транспортным надлежащим уровнем драйвера кусок услуг устройства. Этот кусок представляет APIs, устройство реализует и обеспечивает точку подключения между драйвером блочной системы хранения в уровне услуг устройства и драйвером логической единицы в транспортном уровне драйвера.
Когда драйвер логической единицы загружается для определенного устройства, он публикует соответствующий кусок услуг устройства, содержащий тип устройства в Реестре I/O так, чтобы мог быть загружен надлежащий драйвер блочной системы хранения. Как только драйвер блочной системы хранения загружается, он связывается с объектами в транспортном уровне драйвера через кусок услуг устройства.
Основная ответственность подуровня приложения SCSI состоит в том, чтобы перевести универсальные запросы I/O в специфичные для устройства команды. Это сделано в драйвере логической единицы, определенном для типа устройства. Спецификации Модели архитектуры SCSI определяют несколько категорий устройств, названных типами периферийного устройства. Например, с последовательным доступом устройства, такие как лентопротяжные устройства определяются как тип периферийного устройства, 01$ и принтеры определяется как тип периферийного устройства 02$.
Поскольку ни лентопротяжные устройства, ни принтеры не являются загрузочными или монтируют файловые системы, их драйверы логической единицы не должны быть в ядре. Драйверы логической единицы для периферийных устройств, таких как дисководы для компакт-дисков, которые являются загрузочными и действительно монтируют файловые системы, однако, должны находиться в ядре. Apple обеспечивает, четыре драйвера логической единицы, соответствующие периферийному устройству, вводит 00$, 05$, 07$ и 0$ E:
IOSCSIPeripheralDeviceType00для устройств блочной системы хранения, таких как внутренние дисковые накопителиIOSCSIPeripheralDeviceType05для мультимедийных устройств, таких как CD и DVD-приводыIOSCSIPeripheralDeviceType07для магнитооптических устройствIOSCSIPeripheralDeviceType0Eдля уменьшенных блочных устройств команды, таких как карты флэш-памяти и умные устройства хранения данных
Использование драйвера логической единицы связанный служебный класс вызвало разработчика набора команд для создания вызванного объекта SCSITask. SCSITask объект (описанный более полно в Объекте SCSITask) содержит блок дескриптора команды или CDB, создаваемый из универсального запроса I/O вместе со всеми данными, требуемыми во время продолжительности жизни единственной транзакции I/O. Эти данные включают информацию, такую как потенциальные ошибки, с которыми встречаются, указатели функции обратного вызова и состояние повторной попытки. SCSITask объект является основной единицей транзакций I/O в транспортном уровне драйвера.
Другая часть подуровня приложения SCSI, показанного на рисунке 1-2, является куском периферийного устройства. Функция куска периферийного устройства должна определить, в каком драйвере логической единицы определенное устройство нуждается. Когда устройство обнаружено на шине, кусок периферийного устройства запрашивает его и публикует его тип устройства в Реестре I/O, таким образом, надлежащий драйвер логической единицы может быть загружен для него. После того, как кусок периферийного устройства выполнил свою функцию в здании штабеля драйвера массового хранения, это не вовлечено в последующую обработку запросов I/O.
Подуровень протокола SCSI содержит физическую специфичную для протокола обмена информацию. Драйверы служб протокола, IOUSBMassStorageClass, IOATAPIProtocolTransport, и IOFireWireSerialBusProtocolTransport, ответственны за перевод SCSITask объект получен от подуровня приложения SCSI в специфичный для шины формат. Например, жесткий диск включил шину FireWire SBP-2, понимает CDB в SCSITask возразите, но шина FireWire SBP-2 не делает. Для обработки SCSITask объект, IOFireWireSerialBusProtocolTransport драйвер удаляет CDB и другие элементы от SCSITask возразите и переупаковывает их в блоке запроса работы (или ORB), который понят под шиной FireWire SBP-2.
Уровень услуг устройства
Уровень услуг устройства штабеля драйвера массового хранения предоставляет высокоуровневую поддержку для устройств массового хранения произвольного доступа. Семейство систем хранения поддерживает уровень услуг устройства и ответственно за отправление универсальных запросов I/O через интерфейс, предоставленный куском услуг устройства. Уровень услуг устройства (показанный на рисунке 1-3) состоит из уровня драйвера блочной системы хранения, и произвольное число носителей фильтруют уровни.
Наверху услуг устройства уровень дополнительные уровни фильтра носителей. Каждый уровень фильтра носителей включает драйвер схемы фильтра и мультимедийный объект, который он публикует. Драйвер схемы фильтра является и провайдером и клиентом мультимедийных объектов: Это получает абстрактное массовое хранение запросы I/O от его клиента, выполняет требуемые данные или манипулирование смещением, и передает измененный запрос его провайдеру.
Существует четыре основных вида схем фильтра носителей:
Непосредственный — схема шифрования блочного уровня или схема сжатия, например, соответствуют против одного мультимедийного объекта и производят один мультимедийный объект, представляющий незашифрованное или несжатое содержание.
One-many — Схема выделения разделов, например, соответствует против одного мультимедийного объекта и производит многократные мультимедийные объекты каждое представление содержания одного раздела.
Many-one — Схема RAID, например, соответствует против многократных мультимедийных объектов и производит единственный мультимедийный объект, представляющий совокупное содержание.
Many-many — Носители фильтруют соответствия драйвера против многократных мультимедийных объектов, и производит многократные мультимедийные объекты.
Уровень блочной системы хранения состоит из универсального драйвера блочной системы хранения и мультимедийного объекта, который это публикует. Когда универсальный драйвер блочной системы хранения, надлежащий загрузкам типа устройства, это публикует мультимедийный объект, представляющий устройство в Реестре I/O. В дополнение к представлению устройства мультимедийный объект представляет интерфейс устройству с APIs, реализованным универсальным драйвером блочной системы хранения. Этот APIs включает open, close, read, и write функции, которые являются надлежащими устройству. Мультимедийный объект также имеет свойства, отражающие свойства типа устройства, который он представляет, такие как естественный размер блока и writability.
Между уровнем услуг устройства и транспортным надлежащим уровнем драйвера, кусок услуг устройства. Этот кусок предоставляет интерфейс между универсальным драйвером блочной системы хранения в уровне услуг устройства и специфичным для устройства драйвером логической единицы в транспортном уровне драйвера.
Когда драйвер логической единицы загружается для устройства массового хранения, он публикует соответствующий кусок услуг устройства в Реестре I/O. Надлежащий универсальный драйвер блочной системы хранения соответствует на типе устройства, опубликованном в куске услуг устройства и загрузках. Это тогда передает все массовое хранение запросы I/O через интерфейс, который обеспечивает кусок услуг устройства. Это освобождает универсальный драйвер блочной системы хранения от всего знания определенных команд и механизмов, которые транспортные расположенные на слое объекты драйвера используют для передачи с устройством или шиной.
Реализация штабеля массового хранения
Раздел The Mass Storage Driver Stack описывает штабель массового хранения в архитектурных условиях с только поверхностным отношением к его реализации. В этом разделе описываются объектно-ориентированную реализацию объектов в штабеле и семьях I/O Kit, поддерживающих уровень услуг устройства и транспортный уровень драйвера.
Объекты драйвера массового хранения
Штабель драйвера массового хранения включает объекты Набора I/O, наследовавшиеся от семей I/O Kit. Набор I/O определяет семью как один или несколько классов C++, реализующих абстракции программного обеспечения, характерные для всех устройств определенного типа. Драйвер становится элементом семьи посредством наследования: водительский класс является почти всегда подклассом некоторого класса в семье. Быть элементом семьи означает, что драйвер наследовал переменные экземпляра (структуры данных) и способы поведения, которые характерны для всех элементов семьи.
Когда устройство обнаружено на шине, Набор I/O находит и загружает надлежащий драйвер для него, с помощью отнимающего процесса соответствия (для получения дополнительной информации об этом процессе, посмотрите Лица Драйвера и Соответствие Процесса). Загрузка драйвера вызывает водительскую семью и все другие объекты, от которых зависит драйвер быть загруженным также. Загрузка универсального драйвера блочной системы хранения, например, вызывает загрузку Семейства систем хранения и всех зависимых классов, таких как IOMedia.
Объектно-ориентированный подход Набора I/O для разработки драйвера обеспечивает способ разделить общую функциональность от определенной функциональности и достигнуть модульного и повторно используемого кода. Например, если Ваше устройство является жестким диском FireWire SBP-2, соответствующим спецификациям Модели архитектуры SCSI для устройств блочной системы хранения, драйвера логической единицы Apple IOSCSIPeripheralDeviceType00 достаточно для управления им. Если, однако, Ваш жесткий диск реализует read управляйте по-другому, чем спецификация, можно просто разделить на подклассы IOSCSIPeripheralDeviceType00 драйвер для создания нового драйвера, чей только функционируют, должен переопределить read реализация команды.
Затем путем размещения свойств, уникально описывающих устройство в водительскую индивидуальность, загружается драйвер, когда устройство обнаружено на шине. Ваш драйвер тогда реализует read команда, полагаясь IOSCSIPeripheralDeviceType00 драйвер для реализации остающихся команд, характерных для устройств блочной системы хранения. Точно так же IOSCSIPeripheralDeviceType00 драйвер логической единицы полагается на семью Model архитектуры SCSI для реализации функциональности, необходимой всем драйверам устройств, таким как циклы работы и управление питанием.
Если Вы разрабатываете драйвер схемы фильтра, реализующий шифрование или схему проверки, процесс подобен за исключением того, что Вы не разделяете существующий драйвер схемы фильтра на подклассы. Вместо этого Вы разделяете на подклассы IOStorage и реализуйте надлежащие методы для создания новой схемы фильтра. Затем Ваша дисковая утилита помещает строку, однозначно определяющую Ваше содержание в раздел. В Вашей водительской индивидуальности Вы помещаете ту же строку и когда Набор I/O инициирует соответствие на новых мультимедийных объектах, схема выделения разделов публикует, Ваши соответствия драйвера и загрузки.
Конструкция Штабеля Драйвера Массового хранения описывает здание штабеля драйвера массового хранения в качестве примера и как вписываются разделенный на подклассы драйвер логической единицы и новый драйвер схемы фильтра.
Семья модели архитектуры SCSI
Семья Model архитектуры SCSI поддерживает транспортный уровень драйвера штабеля драйвера массового хранения. Рисунок 1-4 иллюстрирует объем семьи Model архитектуры SCSI путем перечисления большинства ее листовых классов в иерархической диаграмме наследования.
Наверху диаграммы, наследовавшейся от SCSIPrimaryCommands, три разработчика набора команд классы, SCSIBlockCommands, SCSIMultimediaCommands, и SCSIReducedBlockCommands. Каждый разработчик набора команд класс соответствует одному из совместно используемых наборов команд, определенных спецификациями Модели архитектуры SCSI: команды блока SCSI, команды мультимедиа SCSI и SCSI сократили блочные команды.
Каждый разработчик набора команд класс реализует каждую команду, перечисленную в соответствующей совместно используемой спецификации набора команд. Это позволяет инстанцированному разработчику набора команд объект создать a SCSITask объект, который является соответствующим совместно используемой спецификации набора команд устройство, совместим с.
Базовый класс для всех драйверов логической единицы и драйверов служб протокола IOSCSIProtocolInterface. Этот класс обеспечивает методы для отправки, завершения и прерывания команд.
Наследование от IOSCSIProtocolInterface базовый класс подуровня протокола SCSI, IOSCSIProtocolServices, и кусок периферийного устройства, IOSCSIPeripheralDeviceNub. IOSCSIProtocolServices класс обеспечивает модель с очередями для отправки команд через физическое межсоединение. Некоторые из других методов IOSCSIProtocolServices класс обеспечивает, методы для доступа SCSITask возразите и его атрибуты и методы, получающие информацию о CDB в SCSITask объект.
Несмотря на то, что драйверы служб протокола такой как IOFireWireSerialBusProtocolTransport и IOUSBMassStorageClass наследуйтесь от базового класса подуровня протокола SCSI, они не считаются частью семьи Model архитектуры SCSI и поэтому не появляются на рисунке 1-4. Вместо этого они считаются участниками определенных семейств протокола, такими как семья FireWire или семья USB.
Также наследование от IOSCSIProtocolInterface IOSCSIPrimaryCommandsDevice, базовый класс подуровня приложения SCSI. Некоторые методы, которые обеспечивает этот класс, являются методами, чтобы получить, управлять, и выпустить SCSITask объекты и методы, чтобы добраться и выпустить объекты инстанцировали от разработчика набора команд классов.
Три подкласса IOSCSIPrimaryCommandsDevice, IOSCSIMultimediaCommandsDevice, IOSCSIBlockCommandsDevice, и IOSCSIReducedBlockCommandsDevice, соответствуйте трем из совместно используемых наборов команд, определенных в спецификациях Модели архитектуры SCSI. Драйверы логической единицы в ядре являются подклассами этих трех классов.
Несмотря на то, что куски услуг устройства, IOBlockStorageServices, IOReducedBlockServices, IOCompactDiscServices, и IODVDServices, наследуйтесь от базовых классов в Семействе систем хранения, они считаются участниками семьи Model архитектуры SCSI. Эти куски экспортируют APIs от уровня услуг устройства до транспортного уровня драйвера. Каждый кусок экспортирует API, соответствующий типу устройства. Например, IOCompactDiscServices кусок экспортирует специальные методы для чтения оглавления диска, получения и установки громкости, и получения и установки скорости диска.
Наследование от IOUserClient, SCSITaskUserClient класс предоставляет основанным на приложении драйверам доступ к устройствам, которые могут поддерживаться драйверами Модели архитектуры SCSI. SCSITaskUserClient класс обеспечивает интерфейсы устройства для доступа к устройствам (описанный в Интерфейсах Устройства семьи Модели архитектуры SCSI) и не должен самостоятельно быть разделен на подклассы.
SCSITask класс, наследовавшийся от IOCommand, обеспечивает методы, чтобы получить и установить значения SCSITask атрибуты объекта и заполняют CDB среди многих других. SCSITask класс не должен быть разделен на подклассы.
Объект SCSITask
Семья Model архитектуры SCSI обеспечивает логическую единицу и доступ драйверов служб протокола к CDBs через SCSITask объект. SCSITask объект основывается на модели команды SCSI, описанной в разделе 5 из спецификации Модели архитектуры SCSI. Модель команды SCSI определяет формат CDB и нескольких индикаторов состояния, касающихся выполнения команды SCSI. SCSITask объект инкапсулирует эти элементы, давание Вас получает доступ к обширной информации о состоянии команды в дополнение к доступу к самому CDB.
Атрибуты состояния SCSITask объект включает следующее:
Атрибут задачи — определяет, как этой задачей нужно управлять при определении порядка на организацию очередей и представление к надлежащему серверу устройства.
Состояние задачи — представляет текущее состояние задачи такой как новое, включенное, или блокировало.
Состояние Task — представляет состояние завершения задачи.
SCSITask объект также включает информацию, такую как ответ службы от транспортного драйвера, направления передачи данных и буферов памяти. Заголовочный файл, определяющий SCSITask возразите и его методы доступа находится в /System/Library/Frameworks/IOKit.framework/Headers/scsi-commands/SCSITask.h.
Интерфейсы устройства семьи модели архитектуры SCSI
Семья Model архитектуры SCSI обеспечивает механизм интерфейса устройства, позволяющий приложениям отправлять команды в устройства массового хранения, которыми управляют драйверы семьи Model архитектуры SCSI. Для более подробной информации о том, как использовать этот механизм интерфейса устройства, посмотрите Руководство по Интерфейсу Устройства модели архитектуры SCSI.
Существует два режима доступа, доступные приложениям: Монопольный и неисключительный. Эксклюзивный доступ состоит из приложения, действующего как драйвер логической единицы для устройства. Например, если лентопротяжное устройство обнаружено на шине FireWire, кусок периферийного устройства (описанный в Транспортном Уровне Драйвера) публикует тип устройства 01$ в Реестре I/O. Нет никаких драйверов логической единицы в ядре для того типа периферийного устройства так соответствие, и процесс загрузки прибывает в останов.
Когда основанный на приложении драйвер для периферийного устройства вводит запуски за 01$, однако, это находит кусок, представляющий лентопротяжное устройство в Реестре I/O, и инстанцирует a SCSITaskDeviceInterface объект. Это предоставляет неограниченный доступ приложения к устройству — короче говоря, приложение становится драйвером логической единицы.
Неэксклюзивный доступ доступен для исходных приложений. Если CD или DVD-привод обнаружены, Набор I/O находит и загружается, драйвер логической единицы в ядре для периферийного устройства вводят 05$, и остальная часть штабеля создается, как обычно. Пока никакой другой клиент в настоящее время не содержит эксклюзивный доступ к устройству, исходное приложение может получить неэксклюзивный доступ к устройству путем инстанцирования MMCDeviceInterface объект. Это может тогда использовать интерфейс APIs устройства для получения информации, такой как сумма свободного пространства на устройстве.
Если исходное приложение позже требует, чтобы эксклюзивный доступ к устройству, например, записал CD или DVD, это сначала резервирует носители в диске. Тогда это инстанцирует a SCSITaskDeviceInterface возразите и запрашивает эксклюзивный доступ. В этой точке разъединяется управление доходами драйвера логической единицы в ядре к приложению и уровню услуг устройства штабеля массового хранения. Приложение тогда служит драйвером логической единицы, пока это не закрывается, в которой точке драйвер логической единицы в ядре восстанавливает управление, и остальная часть штабеля восстановлена.
Когда приложение имеет эксклюзивный доступ к устройству, это использует объекты, предоставленные третьим интерфейсом устройства, SCSITaskInterface, управлять в ядре SCSITask объекты. Каждый SCSITaskInterface объект соответствует точно один SCSITask объектом, предоставляя приложению тот же доступ к командам обладают драйверы логической единицы в ядре.
Семейство систем хранения
Семейство систем хранения поддерживает уровень услуг устройства штабеля драйвера массового хранения. Рисунок 1-5 показывает Семейство систем хранения в иерархической диаграмме наследования.
Наверху диаграммы абстрактный класс IOBlockStorageDevice. Этот класс объявляет интерфейс к базовым механизмам транспортного уровня драйвера, транспортирующим данные к и от представленного пространства памяти. Массовое хранение запросы I/O проходит через этот интерфейс без любого участия в фактических командах транспортное использование расположенных на слое объектов драйвера для передачи с устройством. Транспортная семья или подклассы драйвера IOBlockStorageDevice, реализует интерфейс APIs и инстанцирует объекта куска услуг устройства. Универсальный драйвер блочной системы хранения тогда управляет этим объектом, равнодушным к специфичным для устройства и специфичным для шины объектам ниже его.
Семья Model архитектуры SCSI объявляет два подкласса IOBlockStorageDevice, куски услуг устройства IOBlockStorageServices и IOReducedBlockServices. Эти куски услуг устройства релейные универсальные запросы с универсального драйвера блочной системы хранения на специфичный для устройства драйвер логической единицы в транспортном уровне драйвера (для получения дополнительной информации об этой семье, посмотрите семью Модели архитектуры SCSI).
Существуют другие семьи и драйверы тот подкласс IOBlockStorageDevice создать куски, обеспечивающие интерфейс между специфичными для устройства транспортными драйверами и универсальным драйвером блочной системы хранения. Они включают транспортный уровень ATA (IOATABlockStorage), USB транспортный уровень UFI и транспортный уровень Образов дисков.
Семейство систем хранения объявляет два подкласса IOBlockStorageDevice: IOCDBlockStorageDevice и IODVDBlockStorageDevice. Эти подклассы обеспечивают протокол для универсального CD и функциональности DVD, независимой от базового физического протокола обмена. Подклассы семьи Model архитектуры SCSI IOCDBlockStorageDevice для куска услуг устройства IOCompactDiscServices и подклассы IODVDBlockStorageDevice для куска услуг устройства IODVDServices.
IOStorage класс является общим базовым классом и для драйвера и для мультимедийных объектов. Это - абстрактный класс, объявляющий основное open, close, read, и write интерфейсы, которые реализуют его подклассы. read и write интерфейсы обеспечивают доступ уровня байта к пространству памяти. IOStorage класс также устанавливает использование мультимедийных объектов протокола для передачи с объектами драйвера, не будучи нужен в мультимедийных объектах, которые будут разделены на подклассы для каждого драйвера.
IOMedia подкласс IOStorage абстракция дискового устройства произвольного доступа. Это обеспечивает непротиворечивый интерфейс и для устройств реального и для виртуального диска, для подразделений дисков, таких как разделы, и для надмножеств дисков, таких как объемы RAID. IOMedia класс реализует надлежащее open, close, read, write, и соответствуя семантику для мультимедийных объектов. Это имеет свойства, отражающие свойства фактических носителей, такие как его общий размер в байтах и выбрасываемо ли это.
Подклассы IOMedia обеспечьте свойства, методы и усовершенствованные интерфейсы, которые являются определенными для мультимедийных объектов DVD и CD. IOCDMedia подкласс включает свойства, такие как тип мультимедийного объекта CD и его оглавления, и реализует методы, читающие специальные области CD. IODVDMedia подкласс включает свойства, описывающие тип мультимедийного объекта DVD, такого как DVD-ROM или DVD-R/W, и реализует дополнительные методы, определенные для DVDs.
IOMediaBSDClient класс публикует интерфейс BSD для всех мультимедийных объектов. IOMediaBSDClient драйвер представляет IOMedia объекты как файлы устройств в OS X среда выполнения BSD. Можно получить доступ к этим файлам устройств с помощью BSD APIs такой как open, close, read, write, и ioctl. ioctl системный вызов обеспечивает методы, чтобы определить различные свойства носителей и управлять различными аспектами носителей. Подклассы IOMediaBSDClient, IOCDMediaBSDClient и IODVDMediaBSDClient, расшириться ioctl поведение включать специфичную для CD и специфичную для DVD функциональность.
Драйверы схемы выделения разделов наследовались от IOPartitionScheme, абстрактный подкласс IOStorage. Apple обеспечивает следующие схемы выделения разделов:
IOApplePartitionScheme, стандартный драйвер схемы выделения разделов AppleIOFDiskPartitionScheme, стандартный драйвер схемы выделения разделов PCIONeXTPartitionScheme, драйвер схемы выделения разделов NeXTIOCDPartitionScheme, драйвер схемы выделения разделов для дорожек CD, требующих лечения как разделов
IOPartitionScheme класс служит основной основой для драйвера схемы выделения разделов, реализующего надлежащее open и close семантика для объектов раздела и значение по умолчанию read и write интерфейсы. Несмотря на то, что open, close, read, и write реализации IOPartitionScheme обеспечивает достаточны для простых схем выделения разделов, более сложные схемы, возможно, должны выполнить больше обработки.
IOBlockStorageDriver подкласс IOStorage общий базовый класс для универсальных драйверов блочной системы хранения. Это расширяется IOStorage протокол путем реализации методов, таких как разблокирование для невыровненных передач, опрос относительно выбрасываемых носителей, и сбор статистики и создание отчетов. Поскольку IOBlockStorageDriver функции независимо от базового устройства и протоколов автобусного транспорта, Вы не должны разделять его на подклассы для обработки особенностей устройства. Новый тип универсального устройства, однако, мог бы потребовать разделения на подклассы IOBlockStorageDriver.
IOCDBlockStorageDriver подкласс IOBlockStorageDriver методы реализаций, поддерживающие CD-приводы, такие как получение информации, связанной с оглавлением и чтением специальных областей диска. IODVDBlockStorageDriver подкласс IOCDBlockStorageDriver методы реализаций, поддерживающие DVD-приводы, такие как получение информации, связанной с шифрованием и ключом для диска.
Схемы фильтра
Упомянутый в Уровне Услуг устройства, драйвер схемы фильтра является оба клиентом IOMedia возразите и провайдер IOMedia объекты. Если Вы интересуетесь разработкой драйвера схемы фильтра, Вы могли бы предположить, что необходимо разделить существующую схему выделения разделов на подклассы. Это является ненужным, однако, потому что можно получить доступ содержанию в существующем разделе. Драйвер схемы выделения разделов, такой как IOApplePartitionScheme, публикует отличное IOMedia объект для содержания каждого раздела. При размещении содержания в разделе драйвер схемы фильтра может соответствовать на уникальном идентификаторе, содержавшемся в довольном свойство подсказки IOMedia объект, представляющий тот раздел (см. рисунок 1-9 для примера того, как это могло бы посмотреть). Как подкласс IOStorage, поэтому, Ваш драйвер схемы фильтра может соответствовать непосредственно на Вашем содержании в разделе и избежать I/O наверху и потенциальных проблем устаревших данных, связанных с активным зондированием носителей для Вашей подписи.
Важно понять, что драйвер схемы фильтра никогда не должен производить IOCDMedia или IODVDMedia объект, потому что эти объекты имеют требования провайдера драйвер схемы фильтра, был бы неспособен встретиться. Например, IODVDMedia объект имеет требования, определенные для носителей DVD это только IODVDBlockStorageDriver (или подкласс), может встретиться. IOMedia объект, с другой стороны, имеет больше универсальных требований что IOStorage подкласс (такой как пользовательский драйвер схемы фильтра) может встретиться. Посмотрите Разработку Схемы Фильтра информации о том, как реализовать драйвер схемы фильтра.
Доступ к объектам IOMedia из приложений
Семейство систем хранения обеспечивает интерфейс устройства для доступа IOMedia объекты из приложений с помощью интерфейса устройства BSD. Каждый IOMedia объект имеет клиентский драйвер BSD, производящий узел устройства (в форме /dev/disk) в OS X среда выполнения BSD. Приложения могут использовать read и write системные вызовы для доступа к данным, представленным IOMedia объект и ioctl системные вызовы для управления специальными характеристиками устройств.
Приложения могут использовать стандартный поиск Набора I/O и уведомление APIs для нахождения определенным IOMedia объекты. Приложение, ищущее CD, например, может создать соответствующий словарь для подкласса IOCDMedia и, использование свойств IOMedia объект публикует, сузьте поиск к выбрасываемым носителям только. Пример этого процесса находится в Руководстве по Доступу Файла устройств для Устройств хранения.
Конструкция штабеля драйвера массового хранения
В этом разделе описывается штабель драйвера массового хранения накоплен от открытия определенного устройства. Затем это показывает, как разделенный на подклассы драйвер логической единицы и новый драйвер схемы фильтра вписываются в штабель.
Иллюстрации в этом разделе используют “форму” части проблемы (показанный на рисунке 1-6) для показа цепочки наследования каждого разделенного на подклассы драйвера.
Наследование работает справа налево: Каждый подкласс блокирует на его наследователя на его правом краю и обеспечивает проекцию для другого (потенциального) подкласса на его левом краю.
Устройство в этом примере является жестким диском FireWire SBP-2. Рисунок 1-7 показывает уровни штабеля, накопленные выше жесткого диска с цепочками наследования, показанными для драйвера логической единицы и драйвера служб протокола.
Когда Вы включаете жесткий диск, контроллер шины FireWire в физическом взаимосвязанном уровне обнаруживает его и инстанцирует IOFireWireDevice объект. IOFireWireDevice возразите сканирует конфигурацию устройства ROM и производит IOFireWireUnit объект для каждого каталога модуля в устройстве. Набор I/O выполняет соответствие на IOFireWireUnit и, так как жесткий диск является устройством FireWire SBP-2, инстанцирует IOFireWireSBP2Target объект.
IOFireWireSBP2Target возразите сканирует конфигурацию устройства ROM и производит IOFireWireSBP2LUN объект для каждой логической единицы это находит. После выполнения соответствия на IOFireWireSBP2Target объект, Набор I/O инстанцирует IOFireWireSerialBusProtocolTransport объект драйвера.
Инстанцирование драйвера служб протокола вызывает инстанцирование куска периферийного устройства, отправляющего команду запроса в устройство. Ответ на этот запрос описывает тип устройства, и кусок периферийного устройства публикует кусок, содержащий ключевой “тип 00 периферийного устройства” в Реестре I/O.
Набор I/O выполняет соответствие на этом куске, в конечном счете нахождение и загрузку IOSCSIPeripheralDeviceType00 драйвер. Когда IOSCSIPeripheralDeviceType00 объект драйвера инстанцирует, соответствующий кусок услуг устройства, IOBlockStorageServices, инстанцирует и инициирует процесс соответствия для драйвера блочной системы хранения.
Когда соответствующий драйвер блочной системы хранения найден, он загружает и публикует IOMedia объект, представляющий целое устройство. Набор I/O тогда находит и загружает драйвер схемы выделения разделов, соответствующий на целом устройстве. Для отформатированных Apple дисков это, вероятно, будет IOApplePartitionScheme. IOApplePartitionScheme тогда публикует IOMedia объект для каждого раздела это находит.
Теперь, предположите, что необходимо поддерживать жесткий диск FireWire SBP-2, реализующий read управляйте по-другому, чем, как определено спецификациями Модели архитектуры SCSI. Вы разделяете на подклассы IOSCSIPeripheralDeviceType00 драйвер и переопределение read метод. Поскольку Ваш драйвер должен быть загружен только для Вашего устройства, Вы помещаете соответствие информации, однозначно определяющей Ваше устройство в Вашем водительском словаре индивидуальности.
Когда I/O, Кит обнаруживает Ваше устройство, оно создает штабель драйвера массового хранения как, прежде чем до него не будет искать драйвер логической единицы. I/O Кит, соответствующий процесс, дает драйвер с большинством соответствующих ключей первый шанс управлять устройством. Начиная с Ваших соответствий драйвера на поставщике, продукте, и возможно даже значениях программного контроля, связанных с Вашим устройством, I/O, Кит одобряет Ваш драйвер по IOSCSIPeripheralDeviceType00 драйвер, соответствующий только на типе периферийного устройства. Ваши загрузки драйвера, вместе с семьей Model архитектуры SCSI и другими зависимостями.
Рисунок 1-8 показывает штабель массового хранения после Вашего драйвера логической единицы (названный «MyLogicalUnitDriver») соответствия и загрузки.
Теперь предположите, что Вы хотите реализовать схему шифрования, перерабатывающую любой транспорт. Этот новый драйвер схемы шифрования соответствовал бы на IOMedia возразите и произведите другого IOMedia объект. Для создания драйвера Вы разделяете на подклассы IOStorage и реализуйте шифрование и поведение дешифрования в водительском read и write методы. Поскольку Ваш драйвер схемы фильтра должен быть загружен только для раздела, содержащего Ваше содержание, Вы помещаете строку довольной подсказки, формы MyCompany_MyContent, в Вашей водительской индивидуальности.
Затем Вы делаете дисковую утилиту доступной, таким образом, пользователь может отформатировать диск для содержания схемы шифрования. Когда дисковая утилита переформатировала диск, она также помещает Вашу строку довольной подсказки в один из разделов.
Когда дисковая утилита выполняет свою задачу, драйвер схемы выделения разделов публикует IOMedia объект для каждого раздела. Это вызывает обновление к Реестру I/O. Набор I/O тогда ищет драйвер схемы фильтра для соответствия на свойстве довольной подсказки в новом IOMedia возразите и это находит всего один — Ваш драйвер схемы шифрования.
Поскольку Ваши соответствия драйвера на той же довольной подсказке представляют в виде строки Вашу дисковую утилиту, помещенную в раздел, нет сомнения, что это - Ваше содержание, таким образом реализовывая probe метод является дополнительным. Если Вы не реализуете probe метод, по умолчанию это возвращается true.
Когда Ваш драйвер схемы шифрования загружается, он публикует IOMedia объект, представляющий незашифрованное содержание на носителях. Рисунок 1-9 показывает штабель драйвера массового хранения после Вашего драйвера, вызванного “MyEncryptionScheme “, загружается.
