Jump to content

Tutorial para crear kexts (traducido al Español)


3 posts in this topic

Recommended Posts

Hola , con permiso de los admisnistradores voy ha postear un tutorial, sobre como crear kexts.....

Util para personas atrevidas y con un poco de conocimiento sobre OS X, para aquellos dispositivos que no conseguimos hacer funcionar en nuestros hackcintosh......

Nota: con permiso de los administradores, pq es un tema muy extenso y  el tutorial sera bastante largo.

 

Introducción

Una extensión del kernel (o kext) es un paquete de carga dinámica de código ejecutable que se ejecuta en el espacio del kernel. Puede crear un kext para realizar tareas de bajo nivel que no se pueden realizar en el espacio de usuario. Los kexts típicamente pertenecen a una de las siguientes tres categorías:

  • Los controladores de dispositivos de bajo nivel
  • Filtros de red
  • Archivos de sistema

Este documento es un recurso primario para la programación kext en OS X. En él se describe la estructura de un kext y demuestra el proceso para desarrollar una kext, desde la creación de un proyecto de Xcode para empaquetar la kext para su distribución.

Quién debería leer este documento?

Este documento está dirigido a los desarrolladores que están desarrollando una extensión del kernel de OS X. Dado que el desarrollo kext cuenta con numerosos escollos, se le anima a mantenerse alejados de la creación de un kext a menos que sea absolutamente necesario. Lea El decidir si prefiere crear una extensión del núcleo” para asegurarse de que un kext es la solución correcta para sus necesidades.

Si está desarrollando un controlador para un dispositivo USB o FireWire, puede y debe ejecutarse en el espacio de usuario. Consulte USB Device Interface Guide y FireWire Device Interface Guide para más detalles.

Estructura de este documento

Este documento contiene los siguientes capítulos:

Guía de programación del kernel proporciona información fundamental de alto nivel acerca de la arquitectura del sistema operativo OS X de imagen.

  • I / O Kit Fundamentos explica la terminología, los conceptos, la arquitectura y los mecanismos básicos del Kit de I / O.
  • I / O Kit Controlador de Dispositivos Instrucciones de diseño describe tareas comunes para llevar a cabo al crear un controlador Kit I / O.

 

Decidir si va a crear una extensión del kernel

A menudo existen alternativas más seguras, más fáciles de crear una extensión de kernel (kext). Es importante asegurarse de que la creación de un kext es absolutamente necesario antes de hacerlo.

Asegúrese de que su código necesita para ejecutarse en el espacio del kernel

La única razón para escribir una kext lugar de una aplicación a nivel de usuario o plug-in es utilizar la funcionalidad que es única al espacio del kernel. Los siguientes casos requieren de código en el kernel residente:

  • El cliente principal de su código reside en el kernel. Controladores del sistema de archivos y la creación de redes de dispositivos entran en esta categoría.
  • Su código se necesita para manejar una interrupción primaria (una CPU Interrupción por hardware). Muchos controladores de dispositivos entran en esta categoría: controladores de red, controladores de gráficos, los controladores de audio, etc. Un controlador de dispositivo USB o FireWire no requiere un kext a menos que su cliente resida en el kernel.
  • Un gran número de aplicaciones requieren un recurso que proporciona su código.

Si el código no cumple ninguno de los criterios anteriores, no escribir un kext. Utilice una de las siguientes soluciones de nivel de usuario en su lugar:

Proceder con Precaución

Si ha determinado que un kext es la solución adecuada para su problema, tenga en cuenta que el desarrollo de un kext es más riesgoso y más difícil que el desarrollo de una aplicación a nivel de usuario, por muchas razones, incluyendo las siguientes:

  • Los kexts reducen la memoria disponible para programas de usuario, ya que el código de espacio de núcleo requiere memoria con cable (no puede extraerse).
  • El entorno de ejecución del kernel tiene muchas más restricciones que el entorno de usuario espacio de tiempo de ejecución, y deben seguirse cuidadosamente para evitar errores. Consulte la Guía de programación del kernel para más  detalles.
  • Los errores de programación en un kext son mucho más graves que los errores en el código de nivel de usuario. Código de espacio del kernel se ejecuta en modo de supervisor, y no tiene ninguna protección contra errores de memoria. En consecuencia, un error de acceso a memoria en un kext causa un pánico del kernel, lo que bloquea el sistema operativo.
  • La depuración de kexts es más difícil que la depuración de los programas a nivel de usuario, ya que requiere dos máquinas y pasos adicionales para configurar una sesión de depuración.
  • Por razones de seguridad, algunos clientes restringen el uso de kexts de terceros.

 

La anatomía de una Extensión del kernel

Los kexts son paquetes que se pueden cargar, y al igual que todos los paquetes que se pueden cargar, se cargan de forma dinámica por otra aplicación. En el caso de un kext, esta aplicación es el propio kernel. Esto tiene muchas implicaciones para los kexts, como se ejecuta en modo supervisor y la capacidad de cargar durante el arranque inicial. Los kexts tienen estrictos requisitos de seguridad y de ubicación que usted debe seguir para que su kext pueda trabajar.

Para entender la anatomía de un kext, usted debe tener un conocimiento básico de los paquetes. Para obtener información general sobre la estructura de un paquete, consulte la Guía de programación Bundle.

Un Kext Bundle por lo general contiene dos componentes principals

En el caso más general, un paquete kext contiene dos componentes: una lista de propiedades de la información y un ejecutable. Junto con estos componentes, un paquete kext puede incluir recursos adicionales y plug-ins. Cada uno de estos componentes se describe aquí

La lista de propiedades de Información

El archivo Info.plist de un kext describe el contenido de la kext. Cada kext debe tener un archivo Info.plist. Debido a que un kext se puede cargar durante el inicio temprano cuando el procesamiento limitada está disponible, este archivo debe estar en formato XML y no puede incluir comentarios. Las siguientes teclas son de particular importancia en el archivo Info.plist de un kext:

  • CFBundleIdentifier se utiliza para localizar un kext tanto en disco como en el kernel. Pueden existir varios kexts con un identificador dado en el disco, pero sólo uno esos kext pueden ser cargado en el kernel a la vez.
  • CFBundleExecutable especifica el nombre del ejecutable de su kext, si tiene uno.
  • CFBundleVersion indica la versión del kext. Números de versión KEXT siguen un patrón estricto (ver “Propiedades Info.plist para las Extensiones del Kernel Extensions”).
  • OSBundleLibraries enumera las Librerias (que son los propios kexts) que son los enlaces del kext.
  • IOKitPersonalities es utilizado por un conductor Kit I/O para cargar el controlador automáticamente cuando sea necesario.

Hay varias claves más en Info.plist-kext especifico que le permiten describir con más detalle el kext. Para una discusión completa de todas las claves Info.plist kext, incluidas las claves q que se refieren a los servicios de tiempo de ejecución específicas del kernel, consulte “Propiedades Info.plist para las extensiones del kernel”

El Ejecutable

Esto va compilado, el código ejecutable de su kext. Su ejecutable es responsable de definir los puntos de entrada que permiten al kernel  cargar y descargar el kext. Estos puntos de entrada varían en función de la plantilla que Xcode utiliza al crear su kext. La Tabla 1 describe las diferencias predeterminadas entre las dos plantillas de Xcode kext. Esta tabla está destinada a ilustrar sólo el uso más común de cada plantilla; el kernel no diferencia entre kexts creados con diferentes plantillas, y es posible incorporar elementos de ambas plantillas en un kext.

Tabla 1  Una comparación de las dos plantillas de Xcode para la creación de un kext

 

Plantilla de extensión del kernel genérico

IOKit plantilla de controlador

Lenguaje de Programación

Por lo general, C

C++

Implementacion

Funciones C registradas como devoluciones de llamada con subsistemas relevantes

Las subclases de una o más clases de controladores Kit de I / O, tales como IOGraphicsDevice

Los puntos de entrada

Iniciar y detener funciones con vinculación C

C + + constructores estáticos y destructores

Cargando comportamiento

Se debe cargar explícitamente

Cargado de forma automática mediante el Kit de I / O cuando se necesite

Comportamiento de descarga

Debe ser descargados de forma explícita

Sin carga de forma automática por el Kit de I / O después de un intervalo fijo cuando ya no es necesario

Tutorial

Crear una extensión del kernel genérico con Xcode”

Creación de un controlador de dispositivo con Xcode”

Algunos kexts no incluyen un ejecutable. Estos kexts (llamados kexts sin código) se utilizan normalmente para decirle Kit I / O para utilizar un controlador existente para su dispositivo. Consulte “Extensiones del kernel sin código Partido nuevos dispositivos a los controladores existentes” para más información.

Recursos adicionales y plug-ins

Los kexts aveces requieren recursos adicionales, como el firmware de un dispositivo. Si su kext requiere un recurso, lo pondra en la carpeta de Resources del paquete de su kext. Si va a localizar sus recursos, tenga en cuenta que el código de espacio del kernel no detecta los recursos localizados. Código de espacio de usuario no detecta los recursos localizados en las subcarpetas.lproj de la carpeta Resources, así que si su recurso se accede sólo por el código del espacio de usuario, la localización es sencilla.

Además de los recursos generales, kexts pueden contener plug-ins, incluyendo otros kexts. Si su kext utiliza un plug-in, lo puso en la carpeta PlugIns de tu kext en construcción. Asegúrese de que el kexts plug-in no contienen plug-in kexts propios; sólo se detecta un nivel de plug-ins con el fin de limitar el recorrido del sistema de archivos durante el inicio(boot).

Extensiones Kernel tienen requisitos estrictos de seguridad

Los kexts se ejecutan en el espacio del núcleo y se ejecutan en modo supervisor; en consecuencia, los archivos y carpetas en un paquete kext deben ser propiedad del usuario root y al grupo wheel. Los archivos deben tener los permisos 0644, y carpetas deben tener los permisos 0755. Un kext que no cumpla estos requisitos no se carga en el kernel.

Durante el desarrollo, para asegurar que su kext tiene la propiedad y los permisos correctamente, cree una copia de su kext como usuario root

% sudo cp -R MyKext.kext /tmp

Password:

Este método requiere la creación de una nueva copia del kext cada vez que construyes.

Extensiones del kernel deben residir en / System / Library / Extensions

OS X busca un kext por su información CFBundleIdentifier clave de la lista de propiedades. Los kexts localizados en /System/Library/Extensions /, y el plug-in kexts de esos kexts, se buscan de manera predeterminada. Puedes realizar una búsqueda personalizada para encontrar kexts en otras carpetas, pero no se recomienda este enfoque. Si su kext necesita ser cargado durante la carga de arranque, debe ser instalado en/System/Library/Extensions , en el sistema operativo para localizarlo.

Extensiones sin código del kernel Partido nuevos dispositivos a los controladores existentes

Un kext sin código es un conjunto del kext que no contiene un archivo ejecutable. IOKitPersonalities de un kext codeless diccionario de nombres de otros kexts que se cargan cuando una personalidad coincide en un dispositivo. Cada uno de estos otros kexts debe tener un ejecutable . Los kexts sin código se utilizan habitualmente con dispositivos USB HID y que son impulsados ​​desde el espacio de usuario. Debido a que el controlador del kernel implementa un protocolo estándar, que puede ser utilizado por casi todos los dispositivos en estas categorías.

Por ejemplo, la mayoría de las impresoras USB comparten un controlador genérico proporcionado por Apple, AppleUSBMergeNub.kext. Apple no puede incluir el diccionario coincidente para todas las impresoras en este kext, así que usted puede instalar un kext sin código con una personalidad que corresponda a su impresora y configure CFBundleIdentifier de la personalidad a com.apple.driver.AppleUSBMergeNub. Cuando la impresora está conectada al ordenador, AppleUSBMergeNub.kext e carga para conducirlo. Listado 1 muestra un ejemplo de tales diccionario IOKitPersonalities de un kext sin código, en formato XML.

Listado 1  El IOKitPersonalities diccionario de un kext sin código

<key>IOKitPersonalities</key>

<dict>

    <key>My_USB_Printer</key>

    <dict>

        <key>CFBundleIdentifier</key>

        <string>com.apple.driver.AppleUSBMergeNub</string>

        <key>IOClass</key>

        <string>AppleUSBMergeNub</string>

        <key>IOProviderClass</key>

        <string>IOUSBInterface</string>

        <key>idProduct</key>

        <integer>0000</integer>

        <key>idVendor</key>

        <integer>0000</integer>

    </dict>

</dict>

Nota: Personalidades de su kext sin código no deben especificar otro kext conductor a menos que el conductor está diseñado para ser ampliado para su uso con dispositivos adicionales. Compruebe el controlador o la documentación de la familia para estar seguro.

 

Crear una extensión del kernel genérica con Xcode

En este tutorial, aprenderá a crear una extensión genérica kernel (kext) para OS X. Se crea un kext simple que imprime mensajes cuando se carga y descarga. Este tutorial no cubre el proceso de carga o la depuración de la kext-ver “Debugging a Kernel Extension with GDB” después de haber completado este tutorial para obtener información sobre la carga y la depuración.

Si no está familiarizado con Xcode, primero lea la Guía rápida Xcode Tour.

Road Map

Estos son los cuatro pasos principales que debe seguir:

1. "Crear un proyecto nuevo"

2. "Implementar las funciones de Start y Stop"

3. "Agregar Declaraciones Biblioteca"

4. "Preparar la extensión del kernel para la carga"

En este tutorial se supone que ha iniciado la sesión como administrador de la máquina, lo cual es necesario para utilizar el comando sudo.

Crear un Nuevo Proyecto (Create a New Project)

Creación de un proyecto kext en Xcode es tan simple como seleccionar la plantilla de proyecto adecuado y proporcionando un nombre.

  1. Iniciar Xcode.
  2. Elija Archivo> Nuevo> Proyecto. Aparece el panel Nuevo proyecto.
  3. En el panel Nuevo proyecto, seleccione Sistema Plug-in en la lista de categorías de proyectos de la izquierda. Seleccione Extensión del kernel Genérico de la lista de plantillas de la derecha. Haga clic en Siguiente.
  4. En la pantalla que aparece, introduzca MyKext para el nombre del producto, escriba un identificador de la compañía, y haga clic en Siguiente.
  5. Elija una ubicación para el proyecto y haga clic en Crear.
  6. Xcode crea un nuevo proyecto y muestra su ventana del proyecto. Debería ver algo como esto:

El nuevo proyecto contiene varios archivos, incluyendo un archivo de origen, MyKext.c, que contiene las plantillas de la funciones  Start y Stop para el kext.

  1. Asegúrese de que está construyendo el kext para las arquitecturas correctas..

(Si no aparece la pantalla anterior, seleccione MyKext en Destinos. Seleccione la pestaña de configuración de generación. Haga clic en el triángulo situado junto a las arquitecturas.)

 Lo siguiente  es activar la Arquitectura a construir. Sólo asegúrese de seleccionar No-esto es especialmente importante si está ejecutando un kernel de 32 bits en un equipo de 64 bits.

Implementar las Funciones Start y Stop

Ahora que ha creado el proyecto, es el momento para hacer su kext haga algo cuando se carga y se descarga. Vas a hacerlo agregando el código de la funciones Start y Stop del kext, que se llamadas cuando su kext se carga y descarga.

Implementar las Funciones Start y Stop

  1. Abrir MyKext.c para editar las funciones Start y Stop.

Figure 1 shows the unedited file.

Figura 1  Viendo el código fuente en Xcode

  1. El valor predeterminado inicia y detiene las funciones no hacen más que devolver un estado de éxito. Las funciones de arranque en un kext real que inicia y detiene, suelen registrar y anular el registro devoluciones de llamada con los sistemas de ejecución del kernel, pero para este tutorial, el kext simplemente imprime los mensajes para que pueda confirmar cuándo se ha iniciado su kext y cuando se detiene.
  2. Editar MyKext.c para que coincida con el código del listado 1.

           Listado 1  MyKext.c contenido del archivo(file contents)

#include <sys/systm.h>

#include <mach/mach_types.h>

 

kern_return_t MyKext_start (kmod_info_t * ki, void * d)

{

    printf("MyKext has started.\n");

    return KERN_SUCCESS;

}

 

kern_return_t MyKext_stop (kmod_info_t * ki, void * d)

{

    printf("MyKext has stopped.\n");

    return KERN_SUCCESS;

}

Observe que MyKext.c incluye dos archivos de cabecera,<sys/systm.h> y <mach/mach_types.h>. Ambos archivos de cabecera residen en Kernel.framework. Al desarrollar su propio kext, asegúrese de incluir sólo los archivos de cabecera desde Kernel.framework (además de los archivos de cabecera que cree), porque sólo estos archivos tienen significado en el entorno del núcleo. Si se incluyen las cabeceras de fuera Kernel.framework, la extensión del kernel se puede compilar, pero probablemente no se podrá cargar o ejecutar porque las funciones y servicios de los encabezados definen no están disponibles en el kernel.

Guarde sus cambios seleccionando Archivo> Guardar.

Edite la Information Property List

Al igual que todos los paquetes, un kext contiene una lista de propiedades de la información, que describe el kext. El archivo Info.plist predeterminado creado por Xcode contiene valores de la plantilla que se debe editar para describir su kext.

El archivo Info.plist de un kext está en formato XML. Siempre que sea posible, usted debe ver y editar el archivo desde Xcode o dentro de la aplicación Plist editor. De esta manera, usted ayuda a asegurar que usted no agrega elementos (como comentarios) que no se pueden analizar por el núcleo durante el arranque inicial.

  1. Haga clic Info.plist en la ventana de proyecto de Xcode.

Xcode muestra el archivo Info.plist en el panel editor. Usted debe ver los elementos del archivo de lista de la propiedad, como se muestra en la Figura 2.

Figura 2  MyKext Info.plist

  1. Por defecto, la lista de propiedades del editor de máscaras de Xcode las teclas reales y los valores de una lista de propiedades. Para ver las claves y valores reales, Control-clic en cualquier lugar en el editor de lista de propiedades y seleccione Mostrar primas claves / valores en el menú contextual.
  2. Cambie el valor de la propiedad CFBundleIdentifier utilice su prefijo de espacio único.
  3. En la línea de CFBundleIdentifier, haga doble clic en la columna Valor para editarlo. Seleccione com.yourcompany cambiarlo a com.MyCompany (o dominio DNS de su empresa a la inversa). El valor debe ser ahora com.MyCompany.kext.${PRODUCT_NAME:rfc1034identifier}.

Bundles en OS X suelen utilizar una convención de nombres DNS inverso para evitar conflictos de espacio de nombres. Esto es particularmente importante para los kexts porque todos los kexts cargados comparten un único espacio de nombres para los identificadores de paquete.

La última porción del identificador de paquete predeterminado,

${PRODUCT_NAME:rfc1034identifier}, se reemplaza por el nombre de la configuración para el destino kext cuando se genera el proyecto de construcción del producto.

Guarde sus cambios seleccionando Archivo> Guardar.

Construir la extensión del kernel (Build the Kernel Extension)

  1. Ahora está listo para configurar los valores de creación y construir su kext para asegurarse de que el código fuente se compila. En primer lugar, configure los valores de creación para construir el kext para cada arquitectura, para asegurarse que su kext cargará independientemente de la arquitectura del kernel.
  2. Haga clic en el triángulo situado junto a objetivos en el panel Grupos y Archivos.
  3. Seleccione el destino MyKext.
  4. Seleccione Archivo> Obtener información. “MyKext” se abre la ventana de Tarjeta de información.
  5. En la lista de opciones, encontrar Build Arquitectura Sólo Activo y asegúrese de que la casilla de verificación no está marcada.
  6. Cierre la ventana Tarjeta de información MyKext.

Ahora que su kext está construyendo en contra de cada arquitectura, elija Generar> Generar para generar el proyecto. Si falla la compilación, corrije todos los errores que te indica y reconstruye antes de continuar.

Añadir Declaraciones de Libreria (Add Library Declarations)

Debido  que los kexts están vinculados en tiempo de carga, un kext debe enumerar sus Librerias en su lista de propiedades de información con la propiedad OSBundleLibraries.

En esta etapa de la creación de su kext, es necesario saber cuáles son esas Librerias. La mejor manera de hacerlo es ejecutar la herramienta kextlibs en su kext construido y copiar su salida en un archivo Info.plist de su kext.

Ejecutar kextlibs en la Extension del Kernel (Run kextlibs on the Kernel Extension)

kextlibs es un programa de línea de comandos que se ejecuta con la aplicación Terminal. Su propósito es identificar Librerias que su kext necesita para enlazar.

Nota: Este tutorial utiliza el signo de dólar ($) del sistema cuando se muestran los comandos que escribas en la aplicación Terminal. Este es el indicador predeterminado del shell bash, que es el shell por defecto en OS X. Si utiliza un shell diferente, es posible que vea un mensaje diferente (el símbolo de porcentaje (%) es otro indicador común).

  1. Inicie la aplicación Terminal, que se encuentra en /Applications/Utilities.
  2. En la ventana de terminal, vaya al directorio que contiene su kext.

Xcode guarda nuestro kext en la carpeta de depuración ( Debug)( a menos que usted haya elegido la configuración de generación diferente o configurar una ubicación diferente para los productos de construcción  (build) que utilizan de diálogo Preferencias de Xcode).

$ cd MyKext/build/Debug

Este directorio contiene su kext. Debe tener el nombre MyKext.kext. Este nombre se forma a partir del nombre del producto como conjunto en la configuración de generación de su objetivo, y un sufijo, en este caso.kext.

  1. Ejecute kextlibs en su extension del kernel extension con la opción -xml  de la línea de comandos.

Este comando busca todos los símbolos no resueltos en el ejecutable de la extensión del kernel entre las extensiones de las Librerias instaladas (en /System/Library/Extensions/) e imprime un fragmento de XML adecuado para pegar en un archivo Info.plist. Por ejemplo:

$ kextlibs -xml MyKext.kext

        <key>OSBundleLibraries</key>

        <dict>

                <key>com.apple.kpi.libkern</key>

                <string>10.2</string>

        </dict>

  1. Asegúrese que kextlibs a salido con un estado correcto comprobando la variable de shell. $?.

$ echo $?

0

  1. Si kextlibs imprime los errores o las salidas con un estado distinto de cero, puede haber sido incapaz de localizar algunos símbolos. Para este tutorial, las Librerias son conocidas, pero en el uso general, usted debe utilizar la herramienta kextfind encontrar bibliotecas para cualquier símbolo que kextlibs no puede localizar. Véase “Locate Kexts” para obtener información sobre kextfind.
  2. Seleccione la salida XML de kextlibs y elija Edición> Copiar.

Agregue las declaraciones de la librería a la Lista de propiedades Información (Add the Library Declarations to the Information Property List)

  1. Anteriormente, ha editado la lista de propiedades de información con el editor de la lista de propiedades gráfica de Xcode. Para esta operación, sin embargo, tiene que editar la lista de propiedades de información en forma de texto.
  2. ontrol-clic Info.plist en la ventana de proyecto de Xcode, a continuación, seleccione Abrir como> Código fuente del archivo en el menú contextual.

Xcode muestra el archivo Info.plist en el panel editor. Usted debe ver el contenido XML del archivo de lista de la propiedad, como se muestra en la Figura 3. Tenga en cuenta que las claves y valores del diccionario se enumeran secuencialmente.

Figura 3  MyKext Info.plist como texto

  1. eleccione todas las líneas que definen el diccionario OSBundleLibraries vacío:

        <key>OSBundleLibraries</key>

        <dict/>

  1. Pegar texto en el diccionario de información.
    • Si kextlibs  se ha ejecutado correctamente, seleccione Edición> Pegar para pegar el texto que ha copiado del Terminal.
    • Si kextlibs no se ejecuta correctamente, escribir o pegar este texto en el diccionario info:

        <key>OSBundleLibraries</key>

        <dict>

                <key>com.apple.kpi.libkern</key>

                <string>10.0</string>

        </dict>

  1. Guarde los cambios seleccionando Archivo> Guardar.
  2. Elija Generar> Generar una última vez para reconstruir su kext con la nueva lista de propiedades de información.

Prepare la extensión del kernel para la carga

Ahora ya está listo para preparar su kext para la carga. Esto se hace con la herramienta kextutil que puede examinar un kext y determinar si es capaz de ser cargado. kextutil también puede cargar un kext para fines de desarrollo, pero esa funcionalidad no está expliacada en este tutorial.

Nota: Este tutorial no cubre realmente la carga de un kext. Por razones de seguridad, no debe cargar su kext en el equipo de desarrollo. Para obtener información sobre la carga y la depuración de un kext con una configuración de dos máquinas, véase “Debugging a Kernel Extension with GDB.”

Establecer permisos de la extensión del kernel

Los Kexts tienen estrictos requisitos de permisos (ver “Kernel Extensions Have Strict Security Requirements” para mas detalles). La manera más fácil de establecer estos permisos es crear una copia de su kext como usuario root. Escriba lo siguiente en la terminal desde el directorio adecuado y proporcionar la contraseña cuando se le solicite:

$ sudo cp -R MyKext.kext /tmp

Ahora que los permisos de copia temporal del kext son correctos, ya está listo para funcionar kextutil.

Ejecutar kextutil

Escriba lo siguiente en la terminal:

$ kextutil -n -print-diagnostics /tmp/MyKext.kext

La opción -n (o -no-load) le dice a kextutil  que no cargue el controlador  y la opción -t (o -print-diagnostics) le dice a kextutil  que imprima los resultados de su análisis a la Terminal. Si ha seguido los pasos anteriores de este tutorial correctamente.kextutil indica que el kext se puede cargar y debidamente vinculada.

No kernel file specified; using running kernel for linking.

MyKext.kext appears to be loadable (including linkage for on-disk libraries).

Nota: Usted puede encontrar un error similar al siguiente:

Warnings:

    Executable does not contain code for architecture:

        i386

Si lo hace, asegúrese de configurar su kext construirlo para todas las arquitecturas, como se describe en "Creación de un nuevo proyecto."“Create a New Project.”

Dónde ir a continuación

¡Felicitaciones! Ahora ha escrito, construido y preparado su propia kext para la carga. En el siguiente tutorial de esta serie, “Creating a Device Driver with Xcode,” usted aprenderá cómo crear un controlador Kit I / O, un kext que permite que el kernel de interactuar con los dispositivos. Si usted no está creando un kit de controladores de E / S, se puede ir directamente a “Debugging a Kernel Extension with GDB,” en el que aprendera cómo cargar un kext, depurarlo y descargarlo con una configuración de dos máquinas.

 

 

Creación de un controlador de dispositivo con Xcode

En este tutorial, aprenderá a crear un controlador de dispositivo Juego de E / S para OS X. Se crea un controlador simple que imprime mensajes de texto, pero en realidad no controla un dispositivo. Este tutorial no cubre el proceso de carga o la depuración de controlador; consulte“Debugging a Kernel Extension with GDB” después de haber completado este tutorial para obtener información sobre la carga y la depuración.

Si no está familiarizado con Xcode, primero lea la Guía rápida Xcode Información.

Road Map

Estos son los principales pasos que seguir:

1. "Familiarizarse con el Kit Arquitectura I / O"

2. "Crear un proyecto nuevo"

3. "Edite la lista de propiedades de la Información"

4. "Rellene el archivo de cabecera"

5. "Implementar los puntos de entrada del conductor"

6. "Agregar Declaraciones Libreria"

7. "Preparar el controlador de carga"

En este tutorial se supone que ha iniciado la sesión como administrador de la máquina, lo cual es necesario para utilizar el comando sudo.

Familiarizarse con el Kit de Arquitectura de I / O

Cada conductor Kit de I / O se basa en una familia, el Kit de I / O, una colección de C + + clases que implementan la funcionalidad que es común a todos los dispositivos de un tipo particular. Ejemplos de familias Kit de I / O incluyen los dispositivos de almacenamiento (discos), dispositivos de red y dispositivos de interfaz humana (como teclados).

Un controlador Kit de I / O se comunica con el dispositivo que controla a través de un objecto proveedor, que normalmente representa la conexión de bus para el dispositivo. Objetos de proveedor que lo hacen se denominan nubs.

Un controlador Kit de I / O se carga en el núcleo de forma automática cuando se coincide (matches) en contra de un dispositivo que está representada por un nub. Un controlador coincida contra un dispositivo mediante la definición de una o más perso nalidades (personalities), las descripciones de los tipos de dispositivo, que el conductor puede controlar.

Después de un controlador Kit I / O coincide con un dispositivo y se carga en el kernel, rutas de E / S para el dispositivo, así como de servicios de vending relacionados con el dispositivo, tales como proporcionar un mecanismo de actualización del firmware.

Antes de empezar a crear su propio conductor, usted debe asegurarse de entender la arquitectura del Kit de I / O mediante la lectura de“Architectural Overview” en I/O Kit Fundamentals.

Crear un Nuevo Proyecto

La creación de un proyecto piloto Kit de I / O en Xcode es tan simple como seleccionar la plantilla de proyecto adecuado y proporcionando un nombre.

  1. Iniciar Xcode.
  2. Elija Archivo> Nuevo> Proyecto. Aparece el panel Nuevo proyecto.
  3. En el panel Nuevo proyecto, seleccione Sistema Plug-in en la lista de categorías de proyectos de la izquierda. Seleccione IOKit controlador de la lista de plantillas de la derecha. Haga clic en Siguiente.
  4. En la pantalla que aparece, introduzca MyDriver para el nombre del producto, escriba un identificador de la compañía, y haga clic en Siguiente.
  5. Seleccione una ubicación para el proyecto y haga clic en Crear.

Xcode crea un nuevo proyecto y muestra su ventana del proyecto. Debería ver algo como esto:

El nuevo proyecto contiene varios archivos, incluyendo un archivo de origen, MyDriver.cpp, que no contiene ningún código.

Asegúrese de que el kext está construyendo para las arquitecturas correctas.

(Si no ve la pantalla anterior, seleccione  MyDriver en Destino (Targets). Seleccione la pestaña de configuración de generación. Haga clic en el triángulo situado junto a las arquitecturas.)

Siguiente construir Active Architecture Sólo asegúrese de seleccionar No-esto es especialmente importante si está ejecutando un kernel de 32 bits en un equipo de 64 bits.

Editar la lista de Propiedades de Información

Al igual que todos los paquetes, un controlador de dispositivo contiene una lista de propiedades de la información, que describe el conductor. Por defecto el archivo Info.plist creado por  Xcode contiene valores de la plantilla que se debe editar para describir su controlador

El archivo Info.plist de un controlador de dispositivo está en formato XML. Siempre que sea posible, usted debe ver y editar el archivo desde Xcode o con la aplicación Editor Plist. De esta manera, usted ayuda a asegurar que usted no agrega elementos (como comentarios) que no se pueden analizar por el núcleo durante el arranque inicial.

  1. Haga clic en Info.plist en la ventana del proyecto Xcode.

Xcode muestra el archive Info.plist en el panel editor. Usted debe ver a los elementos del archivo de lista de la propiedad, como se muestra en la Figura 1.

Figura 1  MyDriver Info.plist

  1. Por defecto, la lista de propiedades del editor de máscaras de Xcode, las claves reales y los valores de una lista de propiedades. Para ver las claves y valores reales, Control-clic en cualquier lugar en el editor de lista de propiedades y seleccione Mostrar primas claves / valores en el menú contextual.
  2. Cambie el valor de la propiedad CFBundleIdentifier utilizar su prefijo de espacio único.
  3. En la línea de CFBundleIdentifier, haga doble clic en la columna Valor para editarlo. Seleccione com.yourcompany y cambiarlo a com.MyCompany (o dominio DNS de su empresa a la inversa). El valor debe ser ahora com.MyCompany.driver.${PRODUCT_NAME:rfc1034identifier}.

Bundles en OS X suelen utilizar una convención de nombres DNS inverso para evitar colisiones de espacio de nombres. Esta convención es particularmente importante para kexts, porque todos los kexts cargados comparten un único espacio de nombres para los identificadores de paquete.

La última porción del identificador de paquete predeterminado,

${PRODUCT_NAME:rfc1034identifier}, se reemplaza por el nombre de la configuración para el destino conductor cuando se genera el proyecto de construcción del producto.

Añadir una personalidad de diccionario IOKitPersonalities del conductor.

Haga clic en la propiedad IOKitPersonalities para seleccionarlo y, a continuación, haga clic en el triángulo desplegable para que apunte hacia abajo.

Haga clic en el  New Child symbol en el lado derecho de la línea seleccionada. Una propiedad titulada New item aparece como hijo de la propiedad IOKitPersonalities. Cambie el nombre de New item a MyDriver.

Hacer que el artículo MyDriver como un diccionario. Control-clic en él y seleccione Tipo de valor> diccionario en el menú contextual.

Su controlador de dispositivo requiere una o más entradas en el diccionario  IOKitPersonalities de su lista de propiedades de la información. Este diccionario define propiedades que se utilizan para hacer coincidir el controlador a un dispositivo y cargarlo.

Rellene el diccionario personalidad.

Crear una entrada de niño por el diccionario MyDriver. Cambie el nombre de New item a CFBundleIdentifier. Copia y pega el valor del valor CFBundleIdentifier (com.MyCompany.driver.${PRODUCT_NAME:rfc1034identifier}) Como valor

Crear un segundo child para el diccionario MyDriver. Cambie el nombre de child a IOClass. Introduzca com_MyCompany_driver_MyDriver como valor. Tenga en cuenta que este es el mismo valor que para el CFBundleIdentifier, excepto que separa sus elementos con guiones bajos en lugar de puntos. Este valor se utiliza como el nombre de la clase para su controlador de dispositivo.

Cree un tercer child para el diccionario MyDriver. Cambie el nombre de child a IOKitDebug. Introduzca 65535 a como el valor y cambiar el tipo de valor de String a Number. Si se especifica un valor distinto de cero para esta propiedad, el controlador proporciona información de depuración útil si coincide y cargas. Cuando se genera el controlador para el lanzamiento público, debe especificar 0 como el valor de esta propiedad o eliminarlo por completo.

Crear dos child más para el diccionario MyDriver. Asigne sus nombres y valores de acuerdo con la Tabla 1.

Tabla 1  MyDriver valores Diccionario personalidad

Nombre

Valor

IOProviderClass

IOResources

IOMatchCategory

com_MyCompany_driver_MyDriver

  • Estos elementos definen conjuntamente una personalidad compatible para su conductor, por lo que se puede cargar. Sirven los siguientes propósitos:
  • IOProviderClass indica la clase del proveedor de objetos que el controlador puede coincidir sucesivamente. Normalmente, un controlador de dispositivo coincide con el nudo que controla el puerto que el dispositivo está conectado. Por ejemplo, si el controlador se conecta a un bus PCI, debe especificar IOPCIDevice como clase de proveedor de conducir. En este tutorial, va a crear un controlador virtual con ningún dispositivo, de modo que coincida en IOResources.
  •  
  • IOMatchCategory permite a otros conductores para que coincidan en el mismo dispositivo como su conductor, siempre y cuando los valores de los pilotos para esta propiedad son distintos. Conductor de este tutorial coincide en IOResources, una clase de proveedor especial que proporciona los recursos de todo el sistema, por lo que debe incluir esta propiedad para permitir a otros conductores para que coincida con el IOResources también. Al desarrollar su conductor, usted no debe incluir esta propiedad a menos que su controlador coincida en un dispositivo que otro conductor puede coincidir con el, como un puerto serie con múltiples dispositivos conectados a él
  •  
  • Cuando haya terminado de agregar elementos de la lista propiedades, la lista debe ser similar al ejemplo que se muestra en la Figura 2.

Figura 2  Info.plist entradas después de las adiciones

  1. Seleccione Archivo> Guardar para guardar los cambios.

Rellene el archivo de cabecera (Fill in the Header File)

Abrir MyDriver.h en la carpeta de origen de su proyecto (Source). Por defecto el archivo de cabecera (header) no contiene ningún código La Figura 3 muestra dónde encontrar el archivo MyDriver.h en la ventana del proyecto.

.

Figura 3  Viendo el código fuente en Xcode

Editar el contenido de MyDriver.h para que coincida con el código del Listado 1.

Listado 1  MyDriver.h contenido del archivo

 

#include <IOKit/IOService.h>

class com_MyCompany_driver_MyDriver : public IOService

{

OSDeclareDefaultStructors(com_MyCompany_driver_MyDriver)

public:

    virtual bool init(OSDictionary *dictionary = 0);

    virtual void free(void);

    virtual IOService *probe(IOService *provider, SInt32 *score);

    virtual bool start(IOService *provider);

    virtual void stop(IOService *provider);

};

 

Observe que la primera línea de MyDriver.h incluye el fichero de cabecera (header) IOService.h. Este archivo de cabecera define muchos de los métodos y servicios que utilizan los controladores de dispositivos. El archivo de cabecera se encuentra en la carpeta IOKit de Kernel.framework. Al desarrollar su propio controlador, asegúrese de incluir sólo los archivos de cabecera de Kernel.framework (además de la cabecera archivos que usted crea), porque sólo estos archivos tienen significado en el entorno del núcleo. Si incluye otros archivos de cabecera, su conductor podría compilar, pero no carga porque las funciones y servicios que se definen en los archivos de cabecera no están disponibles en el kernel.

Tenga en cuenta que cuando usted está desarrollando su propio controlador, debe reemplazar las instancias de com_MyCompany_driver_MyDriver con el nombre de la clase de su conductor.

En el archivo de cabecera de cada clase del controlador, la macro OSDeclareDefaultStructors debe ser la primera línea en la declaración de la clase. La macro toma un argumento: el nombre de la clase. Declara constructores y destructores de la clase para que, de la manera que Kit I / O espera.

  1. Implementar los puntos de entrada del controlador
  2. Abrir MyDriver.cpp en la carpeta de origen (Source). El archivo por defecto no contiene ningún código.
  3. Editar MyDriver.cpp para que coincida con el código del Listado 2.

Listado 2  MyDriver.cpp contenido del archivo

 

#include <IOKit/IOLib.h>

#include "MyDriver.h"

 

// This required macro defines the class's constructors, destructors,

// and several other methods I/O Kit requires.

OSDefineMetaClassAndStructors(com_MyCompany_driver_MyDriver, IOService)

 

// Define the driver's superclass.

#define super IOService

 

bool com_MyCompany_driver_MyDriver::init(OSDictionary *dict)

{

    bool result = super::init(dict);

    IOLog("Initializing\n");

    return result;

}

 

void com_MyCompany_driver_MyDriver::free(void)

{

    IOLog("Freeing\n");

    super::free();

}

 

IOService *com_MyCompany_driver_MyDriver::probe(IOService *provider,

    SInt32 *score)

{

    IOService *result = super::probe(provider, score);

    IOLog("Probing\n");

    return result;

}

 

bool com_MyCompany_driver_MyDriver::start(IOService *provider)

{

    bool result = super::start(provider);

    IOLog("Starting\n");

    return result;

}

 

void com_MyCompany_driver_MyDriver::stop(IOService *provider)

{

    IOLog("Stopping\n");

    super::stop(provider);

}

 

La macro OSDefineMetaClassAndStructors debe aparecer antes de definir cualquiera de los métodos de su clase. Este macro toma dos argumentos: nombre de la clase y el nombre de superclase de su clase. La macro define constructores de la clase, destructores, y varios otros métodos requeridos por el Kit de I / O.

Este listado incluye los métodos de punto de entrada que el Kit de I / O utiliza para acceder a su conductor. Estos puntos de entrada para los fines siguientes:

  • El método init es el primer método de instancia de llamada en cada instancia de su clase controlador. Se llama sólo una vez en cada instancia.. El método free es el último método llamado en cualquier objeto. Cualquier excepcional
  • object. Todos los recursos pendientes que asigna el controlador deben ser desechados de forma free. Tenga en cuenta que el método init funciona en objetos genéricamente; debe utilizarse sólo para preparar objetos para recibir llamadas. Funcionalidad actual conductor debe ser instalado en el método de start.
  • El método probe se llama si su driver necesita para comunicarse con el hardware para determinar si hay una coincidencia. Este método debe dejar el hardware en un buen estado cuando regrese, ya que otros conductores pueden sondear el hardware, así
  • El método start le dice al conductor para iniciar el hardware a conducir. Después arrancar es llamado, el conductor puede iniciar ( start) puede iniciar  el enrutamiento de I/O, publicación de nubs, y servicios de vending. El método  stop es el primer método que se llamará antes de descargar el controlador. Cuando se llama a stop , el conductor debe limpiar cualquier estado en que se creó en su método de start. Los métodos de start y stop de hablar con el hardware a través de la clase de proveedores de su conductor.
  1. La función IOLog s el equivalente del núcleo(kernel) de printf para obtener un controlador Kit I / O.
  2. Guarde los cambios seleccionando Archivo> Guardar.
  3. Genere el proyecto seleccionando Generar> Generar. Corrija los errores de compilación antes de continuar.

Añadir Declaraciones Librerias

Debido a que los kexts están vinculados en tiempo de carga, un kext debe enumerar sus bibliotecas en su lista de propiedades de información con la propiedad OSBundleLibraries. En esta etapa de la creación de su conductor, usted necesita saber cuáles son esas librerias. La mejor manera de hacerlo es ejecutar la herramienta kextlibs en su kext construido y copiar su salida en un archivo Info.plist de su kext.

Ejecutar kextlibs sobre el Driver

kextlibs es un programa de línea de comandos que se ejecuta con la aplicación Terminal. Su propósito es identificar las Librerias que su kext necesita para enlazar.

Nota: En este tutorial se utiliza el signo de dólar ($) del sistema cuando se muestran los comandos que escribas en la aplicación Terminal. Este es el indicador predeterminado del shell bash, que es el shell por defecto en OS X. Si utiliza un shell diferente, es posible que vea un mensaje diferente (el símbolo de porcentaje (%) es otro indicador común).

Inicie la aplicación Terminal, que se encuentra en /Applications/Utilities.

En la ventana de terminal, vaya al directorio que contiene el controlador.

Xcode guarda su controlador en la carpeta de depuración ( Debug) de la carpeta de compilación de su proyecto (build) (a menos que usted haya elegido una configuración de generación diferente o configurado una ubicación diferente para los productos de construcción utilizando el cuadro de diálogo Preferencias de Xcode):

$ cd MyDriver/build/Debug

Este directorio contiene el controlador. Debe tener el nombre MyDriver.kext. Este nombre se forma a partir del nombre del producto, tal como se establece en la configuración de generación de su objetivo, y un sufijo, en este caso.kext.

  1. Ejecute kextlibs sobre el conductor con -xml de la línea de comandos.

Este comando busca todos los símbolos no resueltos en el ejecutable de la extensión del kernel entre las extensiones de las Librerias instaladas (en /System/Library/Extensions/) e imprime un fragmento de XML adecuado para pegar en un archivo Info.plist. Por ejemplo:

$ kextlibs -xml MyDriver.kext

        <key>OSBundleLibraries</key>

        <dict>

                <key>com.apple.kpi.iokit</key>

                <string>10.2</string>

                <key>com.apple.kpi.libkern</key>

                <string>10.2</string>

        </dict>

  1. Asegúrese de que kextlibs ha salido con un estado correcto comprobando la variable de Shell. $?.

$ echo $?

0

  1. Si kextlibs imprime los errores o las salidas con un estado distinto de cero, puede haber sido incapaz de localizar algunos símbolos. Para este tutorial, las Librerias son conocidas, pero en el uso general, usted debe utilizar la herramienta kextfind encontrara Librerias para cualquier símbolo que kextlibs no puede localizar. Consulte la sección “Locate Kexts.”
  2. Seleccione la salida XML de kextlibs y elija Edición> Copiar.

Agregar las declaraciones de la Librería a la Lista de propiedades de Información

  1. Anteriormente ha editado la lista de propiedades de información con el editor de la lista de propiedades gráfica Xcode. Para esta operación, sin embargo, tiene que editar la lista de propiedades de información en forma de texto.
  2. Control-clic Info.plist en la ventana de proyecto de Xcode, a continuación, seleccione Abrir como> Código fuente del archivo en el menú contextual.
  3. Xcode muestra el archive Info.plist en el panel editor. Usted debe ver el contenido XML del archivo de lista de la propiedad, como se muestra en la Figura 3. Tenga en cuenta que las claves y valores del diccionario se enumeran secuencialmente.
  4. Figura 4  MyKext Info.plist archive como texto
  5. Seleccione todas las líneas vacias que definen el diccionario OSBundleLibraries.

        <key>OSBundleLibraries</key>

        <dict/>

  1. Pegar texto en el diccionario info.

Si kextlibs se ha ejecutado correctamente, seleccione Edición> Pegar para pegar el texto que ha copiado del Terminal. Si kextlibs no se ha ejecutado correctamente, escribir o pegar este texto en el diccionario info:

        <key>OSBundleLibraries</key>

        <dict>

                <key>com.apple.kpi.iokit</key>

                <string>10.2</string>

                <key>com.apple.kpi.libkern</key>

                <string>10.2</string>

        </dict>

  1. Guarde los cambios seleccionando Archivo> Guardar.
  2. Reconstruya su controlador (elija Generar> Generar) con la información nueva de la lista de propiedades. Corrija los errores de compilación antes de continuar.

Preparar el Driver para su Carga

Ahora ya está listo para preparar el controlador para la carga. Esto se hace con la herramienta  kextutil, que puede examinar un kext y determinar si es capaz de ser cargado. Kextutil también puede cargar un kext para fines de desarrollo, pero esa funcionalidad no está cubierta en este tutorial

Nota: Este tutorial no cubre la carga de su conductor. Por razones de seguridad, no se debe cargar el controlador en el equipo de desarrollo. Para obtener información sobre la carga y la depuración de un kext con una configuración de dos máquinas, consulte “Debugging a Kernel Extension with GDB.”

Establecer los Permisos del Conductor

Los kexts tienen estrictos requisitos de permisos (ver “Kernel Extensions Have Strict Security Requirements” para más detalles). La manera más fácil de establecer estos permisos es crear una copia de su conductor como el usuario root. Escriba lo siguiente en la terminal desde el directorio adecuado y proporcione la contraseña cuando se le solicite:

$ sudo cp -R MyDriver.kext /tmp

Ahora que los permisos de copia temporal del conductor son correctas, ya está listo para funcionar kextutil.

Ejecutar kextutil

Escriba lo siguiente en la terminal:

$ kextutil -n -t /tmp/MyDriver.kext

La opción -n (o -no-load)  le dice a kextutil que no cargue el controlador, y la opción -t (o -print-diagnostics) le dice a kextutil que imprima los resultados de su análisis a la Terminal. Si ha seguido los pasos anteriores de este tutorial correctamente kextutil  le indicara que el kext se puede cargar y debidamente vinculado.

No kernel file specified; using running kernel for linking.

Notice: /tmp/MyDriver.kext has debug properties set.

MyDriver.kext appears to be loadable (including linkage for on-disk libraries).

Nota: Usted puede encontrar un error similar al siguiente:

Warnings:

    Executable does not contain code for architecture:

        i386

Si lo hace, asegúrese de configurar su kext a construir para todas las arquitecturas, como se describe en “Create a New Project.”

El aviso de la propiedad de depuración se debe al valor distinto de cero de la propiedad IOKitDebug en la lista de propiedades de la información. Asegúrese de que establece esta propiedad en 0 o que lo quite cuando usted construye su controlador para su liberación.

Dónde ir a continuación

¡Felicitaciones! Ahora ha escrito, construido y preparado su propio controlador para la carga. En el siguiente tutorial de esta serie, “Debugging a Kernel Extension with GDB,” usted aprenderá cómo cargar su kext, depurarlo y descargarlo con una configuración de dos máquinas.

 

 

Depuración de una extensión del kernel con GDB (Debugging a Kernel Extension with GDB)

En este tutorial, aprenderá cómo depurar un kext. Se configura un entorno de depuración de dos máquinas y usar GDB para realizar la depuración remota. Si aún no ha creado un kext, completo“Creating a Generic Kernel Extension with Xcode” o “Creating a Device Driver with Xcode” antes de completar este tutorial. Si no está familiarizado con el BGF, vea Depurar con GDB.

Aunque este tutorial está escrito con un controlador de dispositivo como ejemplo, los pasos para la depuración son similares para depurar cualquier tipo de kext.

Road Map

Usted necesita dos máquinas para la depuración remota: una máquina de destino y una máquina de desarrollo. Usted carga y ejecuta el kext en la máquina de destino y depurar el kext en el equipo de desarrollo. Es importante mantener las dos máquinas claras en su mente a medida que trabaja a través de este tutorial, porque usted va a mover hacia atrás y adelante entre ellas muchas veces. Puede ayudar si usted toma un pedazo de papel, lo corta por la mitad, y escribe "Desarrollo" en una mitad y "Destino" en la otra. A continuación, coloque los trozos de papel al lado de las dos máquinas.

Estos son los principales pasos que deberá seguir:

  1. “Configuración preliminar”
  2. “Iniciar GDB y conectar las dos máquinas”
  3. “Depurar el Kernel Extension”

Configuración preliminar

Preparar las máquinas

  1. Preparar las dos máquinas de la siguiente manera:
  2. Asegúrese de que las máquinas se están ejecutando la misma versión de OS X
  3. Asegúrese de que las máquinas están conectadas a la misma red con sus puertos integrados Ethernet.
  4. Asegúrese de que ha iniciado la sesión como administrador en ambas máquinas, lo cual es necesario para utilizar el comando sudo.
  5. Monte la imagen del disco Kernel Debug Kit en el equipo de desarrollo. Descargue el Kernel Debug Kit desde la Apple Developer website bajo la categoría de descarga X OS. Asegúrese de que el Kernel Debug Kit descargado coincide con la versión de OS X instalado en el equipo de destino.

Para obtener más información sobre el Kernel Debug Kit, consulte el archivo Léame incluido en la imagen de disco.

Si el equipo de destino ejecuta OS X Server, desactivar el temporizador watchdog OS X Server.

$ sudo killall -TERM watchdogtimerd

Para obtener más información, consulte la página de manual de watchdogtimerd.

(Máquina de Desarrollo) sabotear la extensión del kernel

  1. Para simular mejor un escenario de depuración del kext real, se necesita su kext pueda producir una situación de pánico del kernel. La forma más fácil de hacer esto es eliminar la referencia de un puntero nulo.
  2. En Xcode, agregue el código siguiente al método de start del conductor (si está depurando un kext genérico, agregarlo a la función MyKext_start del kext):

char *kernel_panic = NULL;

char message = *kernel_panic;

  1. Reconstruir su kext. En la aplicación Terminal, cree una copia de la kext como root:

$ sudo cp -R MyDriver.kext /tmp

  1. Copie el archivo dSYM (en la carpeta de construcción del proyecto de Xcode con su kext) en la misma ubicación que ha copiado su kext.

Transferir la copia de su kext desde el equipo de desarrollo de la máquina de destino.

Si la copia transferida de su kext tiene dueño incorrecto o grupo, corregirlo con el siguiente comando:

$ sudo chown -R root:wheel MyDriver.kext

Advertencia: Asegúrese de que usted no pone el kext en /System/Library/Extensions. Si lo hace, el kext se carga cada vez que reinicie.

(El equipo de destino) Habilitar depuración del kernel

  1. Antes de que pueda depurar el kext, primero debe habilitar la depuración del kernel. En el equipo de destino, haga lo siguiente:
  2. Inicie la aplicación Terminal.
  3. Establecer los indicadores de depuración del kernel.

Para habilitar la depuración del kernel, debe configurar una NVRAM (memoria de acceso aleatorio no volátil) Variable:

$ sudo nvram boot-args="debug=0x144 -v"

Password:

Para obtener más información sobre los indicadores de depuración, consulte “Building and Debugging Kernels” en Kernel Programming Guide.

  1. Reinicie el equipo para que los indicadores de depuración tengan efecto.

Iniciar GDB y conectar las dos máquinas

(El equipo de destino) Obtener la dirección IP del equipo de destino

Nota: Si tiene que reiniciar el tutorial en cualquier momento después de este paso, comenzar con este paso.

Para conectarse a la máquina de destino desde el equipo de desarrollo, usted necesita la dirección IP del equipo de destino. Si usted aún no lo sabe, usted lo puede encontrar en el panel Red de la aplicación Preferencias del sistema.

(Máquina de Desarrollo) Inicie GDB

  1. Inicie GDB con el siguiente comando, lo que indica la arquitectura de la máquina de destino y la ubicación de su kernel de depuración:

$ gdb -arch i386 /Volumes/KernelDebugKit/mach_kernel

  1. Añadir macros específicos del Kernel Debug Kit a la sesión de GDB.

(gdb) source /Volumes/KernelDebugKit/kgmacros

  1. Informar a GDB que usted va a hacer la depuración de un kext remotamente.

(gdb) target remote-kdp

(El equipo de destino) cargar la Extensión Kernel

Ya está listo para cargar su kext y causar un kernel panic. Hacerlo con el siguiente comando:

$ sudo kextutil MyDriver.kext

El pánico del kernel debe ocurrir inmediatamente. La interactividad cesa y la depuración de texto aparece en la pantalla, incluyendo el texto Esperando la conexión del depurador  ( Awaiting debugger connection.)

(Máquina de Desarrollo) Adjuntar al equipo de destino

  1. Ahora usted puede le puede decir a GDB que se inserte en el equipo de destino. En el equipo de desarrollo, haga lo siguiente:
  2. Adjunte el equipo de destino. En el símbolo del BGF, utilice la macro kdp-reattach con el nombre o la dirección IP del equipo de destino:

(gdb) kdp-reattach target.apple.com

  1. El equipo imprime objetivo:

Connected to remote debugger.

(Máquina de Desarrollo) obtener la dirección de carga de la Extensión Kernel

Necesita la dirección de carga de su kext con el fin de generar un archivo de símbolos para ello. Escriba el siguiente en el símbolo del GDB:

(gdb) showallkmods

Aparece una lista con información sobre todos los kext que se ejecutan en la máquina de destino. Encuentre su kext en la lista y anote el valor en la columna de la dirección. Tenga en cuenta que los valores de las columnas kmod y tamaño tienen un aspecto similar al valor de dirección, así que asegúrese de que tiene el valor correcto.

 (Máquina de Desarrollo) Crear y cargar el archivo de símbolos

Puede crear un archivo de símbolos para su kext en la máquina de desarrollo con el comando kextutil. Una vez más, asegúrese de que la versión del Kernel Debug Kit que usted proporciona coincide con la versión de OS X en la máquina objetivo.

  1. Abrir una segunda ventana de Terminal
  2. Crear el archivo de símbolos.

Ajuste la ruta de acceso al Kernel Debug Kit, la ruta a su kext, y la arquitectura del kernel, según corresponda. El camino después de la opción -s especifica el directorio de salida donde se escribe el archivo de símbolos. Este debería ser el directorio en el que copió el archivo kext y dSYM . La opción -n impide que el mandato de la carga del kext en el kernel.

sudo kextutil -s /tmp -n -arch i386 -k /Volumes/KernelDebugKit/mach_kernel -e -r /Volumes/KernelDebugKit /tmp/MyDriver.kext

La herramienta kextutil le pide la dirección de carga de su kext. Proporcionar la dirección de la carga obtenida en el paso anterior.

Cuando termine, el archivo de símbolos está en el directorio de salida indicado. El nombre del archivo es el identificador de conjunto de la kext con la extensión                       .sym

  1. En el símbolo del BGF, especifique la ubicación del archivo de símbolos.

Una vez más, asegúrese de que el archivo de símbolos está en la misma carpeta que la copia de su kext y archivo dSYM.

(gdb) set kext-symbol-file-path /tmp

  1. En el símbolo del BGF, añada su kext para el entorno de depuración con la macro siguiente:

(gdb) add-kext /tmp/MyDriver.kext

  1. BGF le pregunta si desea agregar el archivo de símbolos del kext. Al confirmar, se carga los símbolos.

Depurar la Extensión del kernel

(Máquina de Desarrollo) Depuración con GDB

Ahora ya está listo para comenzar la depuración! Solicite un trazado inverso del BGF para localizar la fuente del pánico:

(gdb) bt

Aparecerá una lista de marcos de pila. Marco de pila de su kext que causó el pánico debe ser fácilmente identificable como sobre el quinto marco de la parte superior. Al depurar sus propios errores de kernel y no sabe la causa, ahora se puede entrar en el marco de pila infractor y averiguar qué causó exactamente el pánico.

Nota: Debido a que la depuración del controlador pasa a un nivel tan bajo, no puede usar algunas funciones del BGF, incluyendo las siguientes:

  • No se puede llamar a una función o un método en el controlador.
  • No se puede depurar rutinas de interrupción.
  • Las sesiones de depuración del kernel no duran indefinidamente. Dado que debe detener el kernel de la máquina de destino para utilizar GDB, inconsistencias internas pueden aparecer que hacen que el kernel entre en pánico o se cuelgue, lo que le obligue a reiniciar el equipo de destino.

(Máquina de Desarrollo) Detener el depurador

Cuando haya terminado la depuración, detenga el depurador para quitar GDB.

(gdb) quit

La sesión de depuración termina. Debido a que el equipo de destino todavía está en pánico, es necesario reiniciarlo. Cuando vuelva a entrar en el equipo de destino, se muestra el siguiente mensaje:

Haga clic en Omitir.

Dónde ir a continuación

¡Felicitaciones! Usted ha aprendido cómo configurar un entorno de depuración de dos máquinas para depurar un kext con GDB. Para aprender a empaquetar su kext para su instalación por sus clientes, lea“Packaging a Kernel Extension for Distribution and Installation.”

 

Herramientas de línea de comandos para el análisis de las extensiones del kernel

Se puede simplificar el proceso de desarrollo kext con las siguientes herramientas de línea de comandos. Más información sobre estas herramientas se pueden encontrar en sus respectivas páginas de manual.

Generar símbolos de depuración y preparación para la carga de kexts

Utilice la utilidad kextutil para generar símbolos de depuración para su kext, y que verifique si el kext se puede cargar. Mientras que usted está depurando su kext, debe utilizar kextutil cargar su kext en lugar kextload.

Las opciones kextutil usadas ​​comúnmente incluyen:

-n / -no-load

No cargar realmente el kext en el kernel. Esta opción es útil cuando sólo desea generar símbolos de depuración o para determinar si un kext se puede cargar.

-s / -symbols

Genera símbolos de depuración para el kext en el directorio especificado después de esta opción.

-t / -print-diagnostics

Salidas de si parece ser cargable el kext o no, junto con un diagnóstico si el kext no parece ser cargable.

-e / -no-system-extensions and -r / -repository

Normalmente se utiliza en conjunto, éstos indican que System/Library/Extensions no se deben utilizar como repositorio kext defecto al resolver las dependencias para su kext, y una carpeta especificada debe utilizarse en lugar.

La utilidad kextutil incluye opciones adicionales para la simulación de diferentes situaciones de carga. Vea la página kextutil manual para más información.

Salida des Estado del kexts Cargado

Utilice la utilidad kextstat para emitir la siguiente información para cada kext cargado en el kernel:

  • El índice de carga del kext (utilizado para rastrear las referencias de enlace)
  • El número de referencias al kext de otros kexts
  • La dirección de memoria del espacio del kernel del kext
  • El tamaño, en bytes, del kext
  • La cantidad de memoria por cable, en bytes, ocupada por el kext
  • El identificador(bundle) del paquete del kext
  • The La versión del paquete kext (bundle version)
  • Los índices de carga de otros kexts que el kext tiene una referencia

Ver kextstat para más información.

Determinar las Dependencias del KEXT

Utilice la utilidad kextlibs para determinar qué la Libreria kexts de su kext debe enlazar con el fin de resolver sus símbolos. Usted debe listar los identificadores de paquetes conjuntos de estas Librerias de los kexts en el diccionario OSBundleLibraries de información de la lista de la propiedad de su kext..

Las opciones kextlibs más usados ​​comúnmente incluyen:

-xml

Produce una salida XML que se puede copiar y pegar en el diccionario OSBundleLibraries de información de la lista de la propiedad de su kext.

-undef-symbols

Muestra símbolos que kextlibs no pudo localizar. Usted puede ser capaz de encontrar estos símbolos utilizando la utilidad kextfind.(Ver Localizar kexts”).

Ver kextlibs para más información.

Localizar kexts

Utilice la utilidad kextfind para buscar kexts con consultas personalizadas. Además de sus predicados de consulta, kextfind incluye predicados para la generación de informes delimitados por tabuladores para su posterior procesamiento.

Los predicados de consulta kextfind más usados ​​comúnmente incluyen:

-dsym / -defines-symbol

Se imprimen sólo los kexts que definen el símbolo especificado después de esta opción. Este predicado es útil para la localización de los símbolos en su kext que kextlibs no puede localizar.

-lib / -library

Devuelve sólo kexts Librería con los que otros kexts pueden enlazar.

La utilidad kextfind contiene muchos más predicados de consulta e informe de los predicados que puede utilizar para afinar su búsqueda. Ver kextfind(8) para más información.

Obtener Cuentas de instancia

Utilice la utilidad IOclasscount obtener el número actual de instancias de cualquier subclase determinada de la clase OSObject C++  (que incluye prácticamente todas las clases incorporadas en el núcleo). El recuento instancia devuelta para una clase incluye el número de instancias de las subclases directas de esa clase. Usted puede utilizar IOclasscount para descubrir casos filtrados que usted debería haber cancelaciones de asignación antes de que se descargue el kext.

Ver IOclasscount para más información.

Ver el Registro Kit I / O

Utilice la aplicación IORegistryExplorer application (ubicado en /Developer/Applications/Utilities) para ver el estado actual del registro del Kit de I / O. IORegistryExplorer también incluye varias opciones de búsqueda y navegación para ayudarle a navegar por el registro.

 

 

Empaquetar una extensión del kernel para la distribución e instalación

Antes de distribuir un kext para la instalación, usted debe prepararse mediante la creación de un paquete. Un kext empaquetado ​​proporciona a los usuarios la información que esperan al instalar el software, tales como las restricciones de licencia y una ubicación de instalación predeterminada. Si aún no ha creado un kext, completo “Crear una extensión genérica Kernel con Xcode” o “Creación de un controlador de dispositivo con Xcode antes de completar este tutorial.

Road Map

Estos son los principales pasos que seguir:

  1. “Establecer permisos para su Kext”
  2. “Crear Información del instalador personalizado”
  3. “Crear un paquete con PackageMaker”
  4. “Construir el paquete de instalación y prueba”

En este tutorial se supone que ha iniciado la sesión como administrador de la máquina, lo cual es necesario para utilizar el comando sudo.

Establecer permisos para su Kext

Antes de empaquetar el kext, es necesario asegurarse de que tiene los permisos adecuados y que reside en un directorio con permisos de root cuando se empaqueta.

  1. Cree un directorio para una copia de su kext en el directorio /tmp como usuario root.

% cd /tmp

% sudo mkdir mykextdir

Password:

  1. Crear una copia de su kext como usuario root y colóquelo en la carpeta que creó.

% cd /KEXT_PROJECT_PATH/build/Release

% sudo cp -R MyKext.kext /tmp/mykextdir/

  1. No cambie los permisos del kext original en la carpeta de compilación del proyecto de Xcode, o de lo contrario se producirán errores cuando se intente reconstruir.

Crear Información del instalador personalizado

Puede incluir información sobre la instalación personalizada en el paquete para mejorar el proceso de instalación para los usuarios. Va a crear un archivo de mensajes de bienvenida, un archivo Read Me, y un archivo de contrato de licencia de software para el paquete con la aplicación TextEdit. Estos recursos suplementarios no deben colocarse en el directorio creado en el paso anterior; en cambio, los pone en la carpeta del proyecto Xcode de su kext.

El Mensaje de Bienvenida

El mensaje de bienvenida es la primera cosa que sus clientes lean al abrir el paquete de la kext. Debe ser una breve introducción al software de su cliente está instalando.

  1. Crear un nuevo archivo en TextEdit.
  2. Introduzca el texto de su mensaje de bienvenida.
  3. Guarde su mensaje de bienvenida como Welcome.rtf en la carpeta del proyecto de su kext.
  4. Cierre el archivo.

El Léame

El Léame describe el contenido de su paquete, información de la versión, y cualquier información adicional que su cliente necesita saber antes de instalar.

  1. Crear un nuevo archivo en TextEdit.
  2. Introduzca el texto de su Léame.
  3. Guarde su mensaje de bienvenida como ReadMe.rtf en la carpeta del proyecto de su kext
  4. Cierre el archivo.

El acuerdo de licencia de software

El acuerdo de licencia de software se describen los términos de uso de su paquete, avisos legales, y las advertencias de software pre-lanzamiento.

  1. Crear un nuevo archivo en TextEdit.
  2. Introduzca el texto de su contrato de licencia de software.
  3. Guarde su contrato de licencia de software como License.rtf en la carpeta del proyecto kexts.
  4. Cierre el archivo.

Después de crear los tres archivos, asegúrese de agregar a su proyecto Xcode seleccionando Proyecto> Añadir a Proyectos; esto asegura que se incluyen en SCM de su proyecto..

Creación de un paquete con PackageMaker

Ahora usted puede utilizar la aplicación PackageMaker para construir un paquete instalable para su kext.

  1. Abrir la aplicación PackageMaker , situado en /Developer/Applications/Utilities.

Aparecerá la ventana principal con una hoja de Instalar propiedades.

  1. Introduzca  com.MyCompany en el campo Organización, y seleccione OS X v10.5 Leopard como el objetivo mínimo. Haga clic en Aceptar.

 

  1. Rellene los campos de la ficha Configuración de la ventana principal de la siguiente manera:

Titulo

MyKext

Ver usuario

Fácil Instalar sólo

Destino de instalación

Volumen del sistema (asegúrese de que todos los demás destinos son instalar sin marcar)

  1. Los campos de certificados y Descripción no son necesarios para este tutorial, pero hay que especificar un certificado para su paquete si desea que se firmó.
  2. Localice la copia de su kext que creó en“Establecer permisos para su Kext” abriendo una ventana del Finder. Elija Ir> Ir a carpeta. Enter/tmp como la carpeta.
  3. Arrastre la carpeta mykextdir de la ventana del Finder y soltarlo en el panel Contenido de la ventana principal PackageMaker. Los principales cambios de vista para mostrar información sobre el paquete mykextdir.
  4. Introducir /System/Library/Extensions en el campo Destino de la ficha Configuración.

Ahora que el paquete tiene todo lo que necesita para la instalación para instalar su kext, puede personalizar la experiencia de instalación para sus clientes.

  1. Haga clic en el botón Editar del interfaz en la esquina superior derecha de la ventana y se abrira la ventana Editor de la interfaz.
    • La primera página del Editor de la interfaz le permite proporcionar una imagen de fondo personalizada para su instalación. Usted no se ha creado una para este tutorial, así que haga clic en Continuar.
    • La segunda página le permite proporcionar el texto de bienvenida personalizado. Seleccione el botón de opción Archivo en la parte derecha del editor y proporcionar la ruta para el archivo de mensaje de bienvenida, haga clic en el menú de engranajes junto al cuadro de texto y eligiendo Elija.
    • La tercera página le permite proporcionar un Léame. Repita el mismo proceso que utilizó para el mensaje de bienvenida, en vez proporcionar el camino para su Léame.
    • La cuarta página le permite proporcionar un contrato de licencia de software. Repita el mismo proceso que utilizó para el mensaje de bienvenida, en lugar proporcionar la ruta de su contrato de licencia de software.
    • La quinta página le permite proporcionar un mensaje de conclusión de encargo. Usted no se ha creado una para este tutorial, así que cerrar la ventana del Editor de la interfaz.
  2. Guarde su progreso mediante Archivo> Guardar. Especifique una ubicación de su elección y entrar MyKextPackage.pmdoc como nombre de archivo.

Añadir las acciones preinstalar y postinstalar(Opcional)

Puede seguir configurando la instalación de su kext especificando las acciones que se ejecutan antes y / o después de instalar el kext. Este tutorial no requiere ningún tipo de acciones, por lo que continuará con el siguiente paso a menos que su kext tenga requisitos específicos preinstalación o postinstalación.

Requerir Reinicio

Si su kext necesita cargar durante el arranque inicial, o si sus Acciones de instalación requieren que se reinicie, configure la opción Reiniciar Acción en la ficha Configuración para requerir reinicio. Instalador le pedirá al usuario que reinicie después de ejecutar cualquier acción postinstalación.

Añadir acciones

Puede asegurarse de que se toman antes y después de instalar el kext ciertas acciones. En el caso de un kext, estas acciones más a menudo implican la carga o descarga otros kexts.

  1. Haga clic en el paquete MyKext en la parte superior izquierda por encima de los contenidos de la vista.
  2. Haga clic en la ficha Acciones.
  3. Haga clic en el botón Editar para cualquiera Preinstalar acciones o postinstall acciones, dependiendo de lo que desee agregar. Aparecera una hoja.
  4. Arrastre las acciones que desee agregar de la lista de la izquierda a la vista de la derecha. Rellene los campos que las acciones requieren.
  5. Ordenar las acciones en la vista arrastrando y soltando, de manera que la primera acción que desea realizar aparezca en la parte superior de la vista.

Guarde su progreso.

Construcción del paquete de instalación y prueba

Ya está listo para construir y probar su paquete.

  1. Seleccione Proyecto> Construir.

Especifique una ubicación de su elección e introducir MyKext.pkg como nombre de archivo.

  1. Haga doble clic en el paquete para ejecutar la aplicación de instalación.

A medida que avance a través del proceso de instalación, los mensajes personalizados que se incluyen aparecerán.

  1. Compruebe que el paquete se ha instalado correctamente.

Vaya a /System/Library/Extensions. Usted debe ver su kext.

 

 

Propiedades Info.plist para las extensiones del kernel

Este apéndice describe las propiedades que puede utilizar para el archivo de Info.plist de su kext.

Propiedades de nivel superior

CFBundleIdentifier

La propiedad CFBundleIdentifier identifica su kext. Dos kexts con el mismo valor de esta propiedad, no pueden ambos ser cargados en el kernel. El valor de esta propiedad debe estar en un formato inversa DNS, por ejemplo com.MyCompany.driver.MyDriver para obtener un controlador Kit I / O o org.MyCompany.kext.MyKext para un kext genérico.

Esta propiedad es obligatoria.

CFBundleExecutable

La propiedad CFBundleExecutable especifica el nombre del código ejecutable de su kext. Xcode automáticamente crea y rellena este valor correctamente para todos los proyectos kext, por lo que no es necesario cambiarlo.

Esta propiedad es necesaria si su kext contiene un ejecutable. Si está desarrollando un kext sin código, no incluya esta propiedad.

CFBundleVersion

La propiedad CFBundleVersion indica la versión de su kext. Números de versión KEXT deben adherirse a un formato estricto:

  • El número de versión se divide en tres partes por períodos, por ejemplo 3.1.2.

El primer número representa la versión principal más reciente, el segundo número representa el más reciente revisión significativa, y el tercer número representa el más reciente de corrección de errores de menor importancia.

El primer número se limita a cuatro dígitos; los segundo y tercero números se limitan a dos dígitos cada uno.

Si el valor del tercer número es 0, puede omitirlo y el segundo período.

  • Durante el desarrollo de una nueva versión de su kext, incluir un sufijo después del número que se está actualizando, por ejemplo 3.1.3a1.

La letra en el sufijo representa la etapa de desarrollo de la nueva versión se encuentra en (desarrollo, alfa, beta, o el candidato final, representado por d, a, b, y fc), y el número en el sufijo es la versión de compilación. La versión de compilación no puede ser 0 o superar 255.

Al soltar la nueva versión de su kext, asegúrese de quitar el sufijo.

Esta propiedad es obligatoria.

OSBundleLibraries

La propiedad OSBundleLibraries es un diccionario que muestra los kexts de la Libreria que enlazan con su kext.

Cada elemento del diccionario consta de un par clave-valor. La clave es la CFBundleIdentifier de la dependencia (como com.apple.kernel.mach), y el valor es la versión necesaria de la dependencia. Cuando un kext está a punto de ser cargado, la versión necesaria de cada elemento en en su diccionario OSBundleLibraries se compara con las versiones actuales y compatibles de la dependencia. Si la versión requerida se encuentra entre la versión actual de la dependencia y su valor OSBundleCompatibleVersion , el kext y sus dependencias se consideran compatibles.

Usted determina los kexts añadir con la herramienta kextlibs de la línea de comandos (ver Determinar Dependencias KEXT ”).

Esta propiedad es necesaria si su kext contiene un ejecutable.

Esta propiedad puede ser específico de la arquitectura (ver  Propiedades Architectura-Especifica”).

OSBundleRequired

La propiedad OSBundleRequired informa al sistema de que su kext debe estar disponible para la carga durante el arranque inicial(boot).Los kexts que no establecen esta propiedad no se pueden cargar durante el arranque inicial(boot). Puede especificar uno de los siguientes valores para esta propiedad:

Root

Se requiere este kext para montar la raíz, sin importar  de donde viene la raíz,por ejemplo, los controladores de la plataforma y las familias, PCI o USB.

Network-Root

Se requiere montar este kext en root,sobre un volumen remoto ---Por ejemplo, la familia de red, controladores de Ethernet, o NFS.

Local-Root

Se requiere montar este kext en root, sobre un volumen local ---Por ejemplo, los sistemas de almacenamiento, controladores de disco o archivos de sistema.

Console

Se requiere este kext para proporcionar soporte de caracteres de la consola (modo monousuario)-por ejemplo, controladores de teclado o la familia ADB.

Safe Boot

Se requiere este kext incluso durante inicio seguro (safe-boot) (desactiva extensiones innecesarias)-por ejemplo, los controladores de ratón o controladores de gráficos.

Esta propiedad puede ser específico de la arquitectura (ver Propiedades específicas de la arquitectura”).

OSBundleCompatibleVersion

La propiedad OSBundleCompatibleVersion se utiliza para activar la vinculación contra un kext como una Libreria. Indica la versión más antigua de la Libreria KEXT con la que otros kexts pueden enlazar y seguir utilizando la versión actual con éxito.

Debe incrementar el valor de esta propiedad cuando se quita un símbolo de la Libreria, o cuando la semántica de un símbolo exportado hacer un cambio lo suficientemente significativo para afectar la compatibilidad binaria.

El formato de este valor es el mismo que el de CFBundleVersion.

Esta propiedad puede ser específica de la arquitectura (ver Propiedades específicas de la arquitectura”).

OSBundleAllowUserLoad

La propiedad OSBundleAllowUserLoad permite a los usuarios que no sean root cargar tu kext. No se recomienda el uso de esta propiedad.

Conductores del kit de I / O no deben incluir esta propiedad, ya que las carga el kernel cuando se necesitan.

Especifique un valor booleano de true para habilitar esta opción.

Esta propiedad puede ser específico de la arquitectura (ver  Propiedades específicas a la arquitectura”).

OSBundleEnableKextLogging

La propiedad OSBundleEnableKextLogging indica que la información de registro específico para su kext debe anotarse en el registro del kernel (disponible en /var/log/kernel.log). La herramienta kextutil habilita automáticamente esta opción para ayudar con la depuración. Especifique un valor booleano de true para habilitar esta opción. Ver kext_logging para más información.

Esta propiedad puede ser específico de la arquitectura (ver Propiedades específicas de la Arquitectura”).

IOKitPersonalities

La propiedad IOKitPersonalities es utilizado por los conductores del kit de I / O. Es un diccionario anidado de información que describe el hardware que el conductor pueda operar.

Ver Propiedades  IOKitPersonalities” para obtener una lista de propiedades para incluir en el diccionario IOKitPersonalities.

Ver Personalidades de controladores y juego Idiomas” en Fundamentos del Kit de I / O para obtener más información sobre las personalidades.

Esta propiedad es necesaria para los conductores del kit de I / O.

Esta propiedad puede ser específico de la arquitectura (ver Propiedades específicas de la Arquitectura”).

Propiedades IOKitPersonalities

IOClass

La propiedad IOClass pregunta  al C++ soble la clase para crear una instancia de su conductor cuando coincide en un nub.

IOKitDebug

La propiedad IOKitDebug indica que los acontecimientos del Kit específico de I / O adjuntando, coincidiendo, y en la exploración se deben registrar en el registro del kernel (disponible en /var/log/kernel.log). El valor de esta propiedad define qué eventos se registran. Para registrar toda la información pertinente, especificar 65535 como valor. Ver IOKitDebug.h (disponible en /System/Library/Frameworks/Kernel.framework/Headers/IOKit) para ver los valores de registro detallados.

IOProviderClass

La propiedad  IOProviderClass pregunta al C ++ sobre la clase del dispositivo del Kit I/O con la que el controlador coincida. Este suele ser el nub que controla el Puerto al que se conecta el dispositivo. Por ejemplo, si el controlador se conecta a un bus PCI, debe especificar IOPCIDevice como clase de proveedor de conductor.

IOMatchCategory

La propiedad IOMatchCategory permite que varios conductores con valores únicos para la propiedad coincidan en la misma clase de proveedor. Por lo general, sólo un conductor puede coincidir en una clase de proveedor dado. Incluye esta propiedad si coinciden con IOResources en un puerto con múltiples dispositivos conectados a él. El valor de esta propiedad debe ser el mismo que el valor de CFBundleIdentifier, El valor de esta propiedad debe ser el mismo que el valor de (por ejemplo com_MyCompany_driver_MyDriver).

IOResourceMatch

La propiedad IOResourceMatch permite declarar una dependencia entre el conductor y un recurso específico, como por ejemplo el kernel BSD o un recurso en particular en un dispositivo, como un jack de audio y vídeo. Si usted proporciona esta propiedad, el controlador no se cargará en el kernel hasta que el recurso especificado está disponible.

Propiedades específicas a la arquitectura

Las Propiedades de nivel superior Info.plist de un kext comienzan con OS o IO tienen versiones específicas de la arquitectura que puede utilizar para diferenciar el comportamiento de su kext en diferentes arquitecturas. Para especificar una propiedad de una arquitectura específica, añada un guión seguido del nombre de la arquitectura a un nombre de la propiedad, por ejemplo, OSBundleCompatibleVersion_x86_64 o OSBundleCompatibleVersion_i386. Asegúrese de mantener la propiedad de la base en su archivo Info.plist por compatibilidad hacia atrás.

 
  • Like 4
Link to comment
Share on other sites

  • 1 year later...
  • 4 months later...
 Share

×
×
  • Create New...