Основной контроль качества

Первый шаг в тестировании Вашего драйвера должен выполнить основную передачу контроля качества. Идеально, многие из этих проверок должны быть частью Вашей ежедневной методологии разработки:

• Корректны полномочия и владение расширения ядра? Для соображений безопасности никакой компонент KEXT не должен быть перезаписываем никаким пользователем кроме суперпользователя. То, что это влечет за собой, то, что:

  • Все файлы и папки в KEXT, включая сам KEXT, должны принадлежать полностью пользователь (UID 0).

  • Все файлы и папки в KEXT, включая сам KEXT, должны принадлежать группе колеса (GID 0).

  • Все папки в KEXT, включая сам KEXT, должны иметь полномочия 0755 (восьмеричный) или rwxr-xr-x (как показано ls -l).

  • Все файлы в KEXT должны иметь полномочия 0644 (восьмеричный) или rw-r--r-- (как показано ls -l). KEXT не является местом для хранения исполнимой программы пространства пользователя.

  В Вашей постсборке и сценариях постустановки, можно установить корректное владение и полномочия расширений ядра с помощью этих команд сценария оболочки:

  /usr/sbin/chown -R root:wheel MyDriver.kext

  find MyDriver.kext -type d -exec /bin/chmod 0755 {} \;

  find MyDriver.kext -type f -exec /bin/chmod 0644 {} \;

  Можно также скопировать драйвер как корень к временному расположению, чтобы дать расширению ядра надлежащее владение и полномочия.

• Вы протестировали драйвер на утечки памяти? Это разгружается должным образом?

  • Загрузите драйвер и затем попытайтесь разгрузить его (использование kextunload); если это успешно не разгружается, то драйвер имеет невыпущенные живые объекты. Необходимо будет разыскать несогласованное, сохраняют и выпускают.

  • Загрузите драйвер и периодически работайте ioclasscount и ioalloccount инструменты на нем. Если Вы видите рост в количестве экземпляров или в типе выделенной памяти, то Ваш драйвер пропускает память.

  • Составьте список каждого класса, который Ваш драйвер непосредственно определяет и каждый класс, которым Ваш драйвер непосредственно управляет (такие как OSString). Создайте вызывающий сценарий командной строки ioclasscount на всех этих классах (Вы не должны вызывать ioclasscount для каждого класса можно перечислить все классы на одной строке), установите систему на коротком цикле следа сна и выполните сценарий каждый раз системные сны и следы. Если Вы обнаруживаете утечку (увеличение счета для класса), разгружаете и перезагружаете Ваш драйвер и выполняете тест снова, чтобы удостовериться, что это - Ваш драйвер, это протекает. Таким образом можно найти утечки, которые могли бы иначе взять тысячи нормальных циклов следа сна для обнаружения.

• Имейте Вы недавно выполнили использование проверок проверки kextload -nt? (См. Отладочные программы для подробных данных.) Эти проверки могут показать необъявленные зависимости и другие ошибки.

• Вы правильно установили или постепенно увеличили номер версии для расширения ядра? Это особенно важно, если Вы хотите, чтобы улучшенная версия Вашего драйвера была выбрана во время процесса соответствия.

Когда Вы будете готовы развернуть драйвер, создайте его с помощью стиля сборки Разработки (в Разработчике Проекта) для получения полного спектра отладочной информации. Сохраните копию драйвера в случае, если Вам или другому разработчику, возможно, когда-либо понадобилась бы symboled версия его. Затем для получения конечного продукта разделите символы от драйвера с помощью strip инструмент. Обратите внимание на то, что Вы используете стиль сборки Разработки вместо стиля сборки Развертывания для заключительной сборки драйвера. Стиль Развертывания представляет дополнительную оптимизацию, делающую мало, чтобы улучшить производительность драйвера и все же сделать ее тяжелее для подхождения символов в разделенных и неразделенных версиях двоичного файла.

Конфигурационное испытание

Конфигурационное испытание стремится тестировать работу Вашего драйвера в ряду факторов что стресс-тест его производительность при различных условиях, возможно показывая скрытую ошибку. Эти факторы включают следующее:

• Многопроцессорные системы. С многопроцессорными системами, бывшими распространенными все больше, важно протестировать Ваш драйвер в таких системах. Ваш код драйвера мог работать на любом процессоре в любой момент. Следовательно, тестирование Вашего драйвера в многопроцессорной системе — где вытеснение и перепланирование происходят одновременно на каждом процессоре — могло бы показать состояние состязания или ошибку блокировки.

• Конфигурации памяти. Необходимо протестировать драйвер в системах в пределах от тех с установленными 128 мегабайтами (текущий минимум) до тех с 1 гигабайтом или более установленный (типичный, например, в системах производства видео).

• Модели компьютера. Необходимо протестировать драйверы на большом разнообразии Питания компьютеры PC: G3 и G4, настольный и переносимый.

• Другие аппаратные средства. Необходимо также протестировать драйвер с варьировавшимися и даже экстремальными выборами присоединенных аппаратных средств. Например, при тестировании драйвера на USB-устройство Вы могли бы протестировать его приблизительно с дюжиной других присоединенных USB-устройств.

• Выпуски OS X. Очевидно, необходимо также протестировать драйвер на диапазоне использующихся в настоящее время версий OS X.

Тестирование управления питанием

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

Если Ваш драйвер для устройства, которое «заменяемо в горячем режиме» (FireWire, USB и плата ПК), протестируйте код в своем драйвере, который ответственен за соединение загрузочно-разгрузочного устройства и (особенно) удаление устройства. Вы хотите гарантировать, что штабель драйвера корректно разъединяется, когда отключено устройство. Как с тестированием управления питанием, разъедините и повторно подключите устройство много раз, чтобы видеть, раскрывает ли чистое повторение события ошибку.

Другие стратегии тестирования и цели

Вот еще несколько предложений, чтобы помочь Вам протестировать свой драйвер:

• Если Ваш драйвер управляет устройством Интерфейса пользователя (HI) или принимает ввод какого-либо вида (такого как драйвер аудио), несомненно, осуществят все возможные типы ввода, включая случаи края. Например, для драйвера клавиатуры Вы могли бы хотеть протестировать различные комбинации, включающие Команду, Управление, Опцию, Escape, Функцию и другие ключи. Для драйверов аудио (что аудиовход управления), Вы могли бы хотеть протестировать, как драйвер выполняет через диапазон звуковых частот.

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

• Наконец, но определенно не в последнюю очередь, всегда рассматривайте свой драйвер с точки зрения безопасности. Если Ваш драйвер полагается на демона пространства пользователя, который является setuid, удостоверьтесь, что исполнимая программа не является мировой перезаписываемой. Проверьте, что процесс установки не представляет возможности для нарушений безопасности и, обычно, что нет никакого способа для неадминистративного пользователя получить контроль над устройством.

Если возможно, можно позволить технической поддержке разработчика Apple связаться, знают, что Вы собираетесь поставить драйвер. Если Вы предоставляете Apple CFBundleIdentifier и версия, однозначно определяющая Ваш драйвер, Apple, будет знать, кто связаться, если проблемный отчет появляется, который, кажется, указывает на Ваш драйвер.

Содержание пакета

Пакет Производителя Пакета Info.plist- базируемый объект NSBundle, содержащий информацию Установщик, требует для установки программного обеспечения в системе OS X. Содержание пакета разделено на требуемые глобальные ресурсы и дополнительные локализуемые ресурсы. Перечисление 8-1 показывает формат пакета под названием MyPackage.

Перечисление 8-1  PackageMaker форматирует для MyPackage

MyPackage.pkg

    Contents

        Info.plist

        Archive.pax.gz

        Archive.bom

        Resources

            /* Optional, localizable package-description information */

            Description.plist

            /* Optional, localizable documents */

            License document

            ReadMe document

            Welcome document

            /* Optional scripts */

            preinstall script

            postinstall script

            preupgrade script

            postupgrade script

            preflight script

            postflight script

            /* Optional check tools */

            InstallationCheck tool

            VolumeCheck tool

            /* Optional, localizable background image */

            background

            /* Optional language project folders. If present, these */

            /* folders contain localized versions of Description.plist, */

            /* License, ReadMe, Welcome, and background files. */

            English.lproj

            Japanese.lproj

Производитель пакета создает пакет Info.plist файл с помощью информации Вы входите в окно Info. Информация, такая как расположение стандартной установки и уровень требуемой авторизации пользователя позволяет Вам настраивать установку содержания своего пакета.

Archive.bom и Archive.pax.gz файлы являются требуемым Производителем Пакета файлов, создает для Вас использующий информацию, которую Вы вводите в окно Files. Archive.bom файл является файлом ведомости материалов, описывающим содержание пакета к Установщику. Archive.pax.gz файл является сжатым архивом, содержащим содержание пакета. (В более ранних версиях Производителя Пакета эти имена файлов включили имя пакета, как в MyPackage.bom и MyPackage.pax.gz.)

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

Необходимо назвать локализуемые документы License.extension, ReadMe.extension, и Welcome.extension, где расширение html, rtf, rtfd, txt, или никакое расширение вообще. В версии 10.2 OS X можно настроить фоновое изображение дисплеи Установщика, когда это открывает пакет. Необходимо назвать файл фонового изображения background.расширение, где расширение jpg, tif, tiff, gif, pict, eps, или pdf.

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

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

Установщик обычно дает пользователю выбор объемов, на которых можно установить Ваш пакет. Если необходимо отключить один или несколько выбора объема, можно обеспечить инструмент VolumeCheck (необходимо назвать инструмент VolumeCheck и сделать его исполнимой программой). Установщик выполняет этот инструмент (если это присутствует), прежде чем это выведет на экран окно Target Select. Как InstallationCheck, VolumeCheck возвращает целочисленный код результата, обрабатывающийся как битовое поле. Установщик использует некоторые биты для идентификации нескольких свойств о состоянии VolumeCheck и других как индекс или в предопределенный или в пользовательский названный файл сообщения об ошибке VolumeCheck.strings.

Метапакет является просто пакетом предварительно созданных пакетов. Если, например, Вы предлагаете комплект драйверов, можно создать метапакет для содержания их всех, и позволить клиентам устанавливать тех они выбирают. Для создания метапакета выберите Новый Пакет Меты из меню File Производителя Пакета.

Метапакет имеет те же компоненты как единственный пакет с добавлением списка подпакетов (каждый из которых должен быть допустимым пакетом). Для конкретных различий в Info.plist ключи, посмотрите Примечания Формата Пакета Производителя Пакета.

Проверка пакета и установка

Производитель пакета обеспечивает инструмент проверки, можно работать пакете для установки флага потенциальных проблем (для выполнения его, выберите Validate Package в меню Tools). Можно выполнить инструмент на пакетах, созданных с любой версией Производителя Пакета. Инструмент проверяет на присутствие требуемых файлов и что сценарии являются исполнимой программой. Допустимый пакет должен содержать

• a. файл змеи

• a .pax.gz файл, если пакет не является получением или имеет ключ Alternate Source Location или набор ключей Расположения Пакета Прокси (эти ключи определяется в Примечаниях Формата Пакета Производителя Пакета),

• Info.plist файл (для пакетов, созданных с новейшей версией Производителя Пакета) или .info файл (для пакетов, созданных с более старыми версиями Производителя Пакета)

• a .sizes файл, если пакет создается с более старой версией Производителя Пакета

• исполнимые сценарии и инструменты, если присутствуют сценарии и инструменты

Допустимый метапакет должен содержать

• a .list файл, если метапакет создается с более старой версией Производителя Пакета

• список пакета выстраивает в Info.plist файл, если метапакет создается с более новой версией Производителя Пакета

• если метапакет создается с более новой версией Производителя Пакета, подпакеты перечислили в массиве списка пакета

Когда Установщик устанавливает единственный пакет, он выполняет следующие шаги:

1. Выполните сценарий InstallationCheck (если есть).

2. Выведите на экран Экран приветствия.

3. Выведите на экран экран ReadMe.

4. Выведите на экран экран License.

5. Выполните сценарий VolumeCheck (если есть) для каждого доступного объема.

6. Выведите на экран экран выбора объема.

7. Ожидайте пользователя, чтобы выбрать целевой объем и нажать Install.

8. Выполните сценарий перед рейсом, если существующий.

9. Выполните предварительно устанавливать сценарий (или предварительно обновите сценарий, если это - обновление), если существующий.

10. Скопируйте файлы в целевой диск (если это - обновление, некоторые файлы могут быть скопированы в промежуточный каталог сначала).

11. Выполните сценарий постустановки (или постобновите сценарий, если это - обновление), если существующий.

12. Если это - обновление, скопируйте файлы в промежуточном каталоге их конечному месту назначения.

13. Скопируйте получение в папку Receipts целевого диска.

14. Выполните послеполетный сценарий, если существующий.

15. Перезагрузка или выход, в зависимости от флагов пакета.

Установщик выполняет подобный набор шагов при установке метапакета:

1. Выполните сценарий InstallationCheck, если существующий.

2. Выведите на экран Экран приветствия.

3. Выведите на экран экран ReadMe.

4. Выведите на экран экран License.

5. Выполните сценарий VolumeCheck (если есть) для каждого доступного объема.

6. Выведите на экран экран выбора объема.

7. Ожидайте пользователя, чтобы выбрать целевой объем и нажать Install.

8. Выполните следующие шаги для каждого подпакета

   1. Выполненный сценарий перед рейсом, если существующий.

   2. Выполните предварительно устанавливать сценарий (или предварительно обновите сценарий, если это - обновление), если существующий.

   3. Скопируйте файлы в целевой диск (если это - обновление, некоторые файлы могут быть скопированы в промежуточный каталог сначала).

   4. Выполните сценарий постустановки (или постобновите сценарий, если это - обновление), если существующий.

   5. Если это - обновление, скопируйте файлы в промежуточном каталоге их конечному месту назначения.

   6. Выполните послеполетный сценарий, если существующий.

9. Перезагрузка или выход, в зависимости от флагов метапакета.

При использовании другого инструмента для создания пакета, необходимо исследовать установленные файлы тщательно, чтобы удостовериться, что все - то, где Вы хотите, чтобы он был.