Свопинг байта

Как разработчик драйвера устройства, Вы остро знаете о собственном формате порядка байтов устройства, с которым Вы работаете. Это знакомство, вместе с фактом, что процессор PowerPC использует порядок байтов с обратным порядком байтов, может означать, что Ваш код делает предположения порядка байтов, которые не являются подходящими для универсального двоичного файла. Если, например, драйвер устройства связывается с исходно устройством с прямым порядком байтов (таким как USB-устройство), он может выполнить little-big подкачки байта, потому что он был разработан для выполнения в основанном на PowerPC Macintosh. Когда драйвер устройства будет выполнен в основанном на Intel Macintosh, такие трудно кодированные подкачки байта вызовут проблемы.

Для предотвращения этих проблем поиск трудно кодированного байта загружает драйвер устройства, и замените их условными подкачивающими байт макросами, определенными в libkern/OSByteOrder.h. Они макросы разработаны для выполнения самой эффективной подкачки байта для данной ситуации. Например, использование OSSwapConst макросы (и OSSwap*Const варианты) в OSByteOrder.h подкачивать постоянные значения предотвращает свопинг байта во время выполнения.

Обработка архитектурных различий

Как описано в Универсальных Двоичных Инструкциях по Программированию, Втором Выпуске, существуют различия в PowerPC и x86 архитектуре, которая может предотвратить код, разработанный для одной архитектуры из выполнения должным образом в другой архитектуре. Этот раздел выделяет два архитектурных различия, сделавшие разработчиков драйвера устройства последствий, должен знать.

В основанном на Intel Macintosh целочисленная работа деления на нуль является фатальной, тогда как в основанном на PowerPC Macintosh (в котором работа возвращается 0), это не. Несмотря на то, что маловероятно, что Ваш драйвер устройства намеренно выполняет работу деления на нуль, это может произойти в результате других операций. Исследуйте свой код на места, где это могло бы произойти и добавить код для предотвращения его.

Драйверы устройств часто определяют структуры данных программного обеспечения те зеркальные аппаратные средства структуры данных. Важно понять, что некоторые типы данных имеют один размер в одной архитектуре и различный размер в другом. Например, bool тип данных составляет один байт в x86 архитектуре и четыре байта в архитектуре PowerPC. Если Ваш драйвер устройства использует структуру данных, содержащую a bool оцените, полагайте, что замена его с типом данных фиксированного размера избегает проблем выравнивания.

Просмотр значений в плоскости дерева устройств

В основанном на PowerPC Macintosh Откройте, Firmware заполняет плоскость дерева устройств Реестра I/O с информацией об иерархии устройства. В основанном на Intel Macintosh плоскость дерева устройств может содержать полностью различные значения. Фактически, плоскости дерева устройств различных основанных на PowerPC компьютеров Macintosh могут содержать различные значения.

Поскольку Вы не можете предсказать то, что оценивает плоскость дерева устройств личного компьютера, будет содержать, Ваш драйвер устройства не должен полагаться на существование определенных значений или расположений. Вместо этого это должно использовать APIs, предоставленный классами Набора I/O, такими как IORegistryEntry, к значениям доступа в Реестре I/O.

Прерывание, совместно использующее в основанном на Intel Macintosh

Для Вашего драйвера устройства важно провести любые прерывания, которые это могло бы получить, которые не направлены на него. В основанном на PowerPC Macintosh каждый внутренний разъем PCI имеет свою собственную специализированную линию прерывания, что означает, что драйвер мог бы быть в состоянии сойти с рук игнорирование прерываний, не предназначенных для него, даже при том, что это не рекомендуется. В основанном на Intel Macintosh, однако, вероятно, что драйвер совместно использует линию прерывания с другими драйверами. При этих обстоятельствах, игнорируя прерывания для других драйверов может вызвать проблемы для этих драйверов и для пользователя.

Возможно, что Ваш драйвер мог бы получить очень большое количество прерываний, предназначенных для других драйверов. Помимо того, чтобы быть убеждающимся передать их, Ваш драйвер не должен рассматривать поступление таких прерываний как событие, требующее своего рода регистрации ошибок. Если, например, Ваше использование драйвера IOLog для журналирования каждого ложного прерывания, это получает, это быстро переполнит консольного журнала и может ухудшить производительность системы. (Для получения дополнительной информации об использовании IOLog, посмотрите Используя IOLog.)

Используя функцию OSSynchronizeIO

Ваш драйвер устройства PowerPC может использовать OSSynchronizeIO функционируйте к, например, осуществите чтобы выполнение операции записи. В основанном на PowerPC Macintosh эта функция выходит eieio инструкция. В основанном на Intel Macintosh, однако, эта функция ничего не делает, потому что x86 архитектура поддерживает сильную память, упорядочивающую по умолчанию.

Универсальная версия двоичных файлов драйвера устройства, использующего OSSynchronizeIO функция должна продолжать делать так, чтобы гарантировать, что она все еще работает правильно на основанном на PowerPC Macintosh.

Доступ к Пространству I/O

В основанном на PowerPC Macintosh PCI пространство I/O отображается в память. Драйвер устройства PCI получает доступ к пространству I/O с помощью ioRead* функции класса IOPCIDevice (для больше на этих функциях, посмотрите IOPCIDevice документация в Ссылке Платформы Ядра). В основанном на PowerPC Macintosh эти функции переводят в доступы памяти, и в основанном на Intel Macintosh они переводят в надлежащие x86 инструкции. При разработке универсальной версии двоичных файлов драйвера PCI, поэтому, можно использовать ioRead* функции для доступа к пространству I/O и драйверу будут работать и в основанных на PowerPC и в основанных на Intel компьютерах Macintosh.

Для других устройств, использующих пространство I/O, однако, такое как контроллер ATA, Вам, вероятно, придется добавить x86-специфичные инструкции, выполняющиеся, когда драйвер работает на основанном на Intel Macintosh.

Отладка на основанном на Intel Macintosh

По большей части отладка драйвера устройства, работающего на основанном на Intel компьютере Macintosh, совпадает с отладкой драйвера, работающего на основанном на PowerPC компьютере Macintosh. Даже при том, что основанный на Intel компьютер Macintosh использует EFI (расширяемый микропрограммный интерфейс) вместо Открыть Firmware, используемого в основанном на PowerPC компьютере Macintosh, все еще необходимо установить надлежащий NVRAM (энергонезависимый RAM) переменные для включения отладки с двумя машинами (для получения дополнительной информации об отладке с двумя машинами, посмотрите Отладку С двумя машинами). Для изменения переменных NVRAM на любом компьютере Macintosh рабочий OS X Вы используете nvram утилита как root на командной строке. Например, можно установить следующий флаг отладки ядра:

nvram boot-args="debug=0x14e"

Основанные на Intel компьютеры Macintosh также обеспечивают способ сохранить персистентный набор загрузочных аргументов на определенной машине. Набор загрузочных аргументов не требуется для отладки ядра, но это может упростить для Вас, если Вы часто выполняете netbooting или если бы Вы загружаетесь от различных разделов, и требуется связать различные загрузочные аргументы с каждым разделом.

Загрузочные аргументы содержатся в названном файле списка свойств com.apple.Boot.plist, который расположен в /Library/Preferences/SystemConfiguration. com.apple.Boot.plist файл содержит следующие ключи:

• Графика начальной загрузки. Это устаревшее свойство использовалось, чтобы определить, нарисован ли логотип Apple во время начальной загрузки. Вместо этого используйте -v флаг загрузочного аргумента для отключения графики времени начальной загрузки.

• Ядро. Значение свойства Kernel идентифицирует ядро для начальной загрузки. Значение по умолчанию mach_kernel, но можно использовать это свойство для выбора альтернативного ядра, такого как экспериментальное ядро или ядро отладки.

• Флаги ядра. Свойство Kernel Flags может содержать любой набор допустимых флагов, такой как debug=0x144, разделенный пробелами. По умолчанию значение этого свойства является пустой строкой.

Если Вы выполняете netbooting, несомненно, сделают копию com.apple.Boot.plist файл и место это в той же папке, содержащей ядро на netboot сервере. Типичный сценарий разработки должен иметь ядро, mkext файл (ранее кэшируемый набор драйверов устройств для аппаратных средств, вовлеченных в процесс начальной загрузки), и a com.apple.Boot.plist файл для каждой netboot конфигурации Вы работаете с.