Разработка Универсального двоичного файла
Если Вы планируете создать универсальную версию двоичных файлов своего драйвера логической единицы, драйвер служб протокола или схема фильтра, сначала считал Универсальные Двоичные Инструкции по Программированию. Тот документ касается архитектурных различий, и порядок байтов форматирует и обеспечивает всесторонние инструкции для модификации кода и создания универсальных двоичных файлов. Затем чтобы узнать, как решить, в какой версии компилятора и SDK Вы нуждаетесь, см. “Разработку Драйвера устройства для Работы Основанного на Intel Macintosh” в Руководстве по проектированию Драйвера устройства IOKit.
Эта глава кратко обрисовывает в общих чертах несколько специфичных для массового хранения проблем, которые необходимо иметь в виду, поскольку Вы создаете универсальную версию двоичных файлов своего драйвера или фильтруете схему.
Создание драйвера служб логической единицы или протокола Универсальный двоичный файл
Поскольку Вы создаете универсальную версию двоичных файлов своей логической единицы или драйвера служб протокола, знать о местах в Вашем коде, где Вы могли бы сделать предположения о порядке байтов многобайтовых численных значений. Обязательно замените любые трудно кодированные подкачки байта (такие как код, всегда подкачивающий многобайтовое значение от обратного порядка байтов до прямого порядка байтов) с надлежащими условными подкачивающими байт макросами, определенными в libkern/OSByteOrder.h
.
Например, предоставленное Apple IOSCSIBlockCommandsDevice
класс содержит код, использующий подкачивающий байт макрос, определенный в OSByteOrder.h
подкачивать два четырехбайтовых поля в a SCSI_Capacity_Data
структура, как показано в Перечислении 4-1. ( SCSI_Capacity_Data
структура определяется как полная структура возврата для READ_CAPACITY 10
команда в SCSICmds_READ_CAPACITYDefinitions.h
заголовочный файл.)
Свопинг байта перечисления 4-1 в коде IOSCSIBlockCommandsDevice
bool IOSCSIBlockCommandsDevice::DetermineMediumCapacity (UInt64 * blockSize, UInt64 * blockCount) { |
SCSI_Capacity_Data capacityData = {0}; |
... |
*blockSize = 0; |
*blockCount = 0; |
... |
// Create and send READ_CAPACITY command. |
// If the command completed successfully: |
*blockSize = OSSwapBigToHostInt32 (capacityData.BLOCK_LENGTH_IN_BYTES); |
*blockCount = ((UInt64) OSSwapBigToHostInt32 (capacityData.RETURNED_LOGICAL_BLOCK_ADDRESS)) + 1; |
... |
} |
В целом данные возвратились из устройств, соответствующих спецификациям Модели архитектуры SCSI, находится в формате с обратным порядком байтов. К счастью, однако, спецификация модели команды SCSI определяет CDB (блок дескриптора команды) как массив байтов. Это означает, что байты сохранены в определенном порядке независимо от собственного формата порядка байтов компьютера, в котором работает драйвер.
Создание схемы фильтра Универсальный двоичный файл
Поскольку Вы создаете универсальную версию двоичных файлов своего драйвера схемы фильтра, знать, что схемы фильтра часто обрабатывают структуры данных, считанные из или записанные в диск. Важно, что структура данных на диске остается в корректном формате порядка байтов, таким образом, диск может использоваться и с основанными на PowerPC и с основанными на Intel компьютерами Macintosh. В зависимости от собственного формата порядка байтов компьютера, в котором Ваш драйвер схемы фильтра работает, поэтому, Ваш драйвер, возможно, должен к байту подкачать структуры данных, которые это обрабатывает.
Если Вы решили, что свопинг байта необходим, можно реализовать его любым из следующих двух способов:
Выполните надлежащий байт, загружают память, когда структура данных читается в из диска, и выполните противоположную подкачку байта, когда структура данных выписана к диску. Это означает, что Ваш драйвер может получить доступ к структуре данных в памяти, не имея необходимость волноваться о формате порядка байтов структуры данных.
Не подкачивайте формат порядка байтов структуры данных, в то время как это находится в памяти, но выполните надлежащую подкачку байта на каждом доступе. Это сохраняет структуру данных в корректном формате порядка байтов для диска, в то время как это находится в памяти, что означает, что Ваш драйвер не имеет к подкачке байта структуры данных при чтении его в или выписывания его.
Для предотвращения беспорядка, лучше выбрать только одну из этих двух альтернатив и быть непротиворечивым в его реализации. Какой бы ни опция Вы выбираете, однако, убедиться использовать условные подкачивающие байт макросы, определенные в libkern/OSByteOrder.h
. При использовании их макросы компилятор оптимизирует код, таким образом, подпрограммы выполняются, только если они необходимы для архитектуры, в которой работает драйвер.
Например, встроенный драйвер схемы выделения разделов Apple, IOApplePartitionScheme
, использует подкачивающий байт макрос, определенный в OSByteOrder.h
подкачивать двухбайтовое поле в a dpme
структура, как показано в Перечислении 4-2. ( dpme
структура определяется как запись карты раздела диска в IOApplePartitionScheme.h
заголовочный файл.)
Свопинг байта перечисления 4-2 в коде IOApplePartitionScheme
OSSet * IOApplePartitionScheme::scan (SInt32 * score) { |
... |
dpme * dpmeMap = 0; |
... |
// Read in a partition entry and assign to dpmeMap. |
... |
// Determine whether the partition entry signature is present. |
if (OSSwapBigToHostInt16(dpmeMap->dpme_signature) != DPME_SIGNATURE) |
... |
} |