Jump to content

XAVIDENIA

Members
  • Content Count

    146
  • Joined

  • Last visited


Reputation Activity

  1. Like
    XAVIDENIA got a reaction from Maniac10 in (SOLUCIONADO)Ocultar efi en clover   
    solucionado pero no como tu me aconsejaste pues tras estar un buen rato probando no conseguí el resultado que quería , así que dejo solucion por si a alguien mas le pasa.....
    la solución paso por desconectar el resto de discos duros , para no tener tanta información , crear un dump con el darwindumper  y sorpresa  el nuevo boot de Ubuntu lleva entradas o path para todas las distribuciones, como podrás ver aquí......
     
     
    con lo cual no se trataba de ocultar shimx64.efi, sino de especificarle la entra exacta a Ubuntu , según la distribución  instalada , añadiendole el path a uuid volume  efi  en mi caso el volume uuid es 7149364A-458C-496B-8EFA-3D6E62F073F0
    y el path \EFI\ubuntu\grubx64.efi y simplemente con eso ya sale solo una entrada de Ubuntu al iniciar el pc
     
    Gracias maniac
  2. Like
    XAVIDENIA got a reaction from Maniac10 in (Solucionado) ayuda con Clover y power management   
    si claro ahora te subo un reporte DD
     
    ok veo que hay muchos dispositivos hdmi deshabilitados probare uno a uno a ver
     

     
    cual me aconsejais que pruebe primero....

    He probado con todos los conectores activando uno por uno y ninguno me activa el audio hdmi
     
     
    Solucionado audio hdmi
     
    estaba renombrando la grafica que es gfx0 a igpu
     

     
    luego en kernel and patches he activado una salida hdmi....
     

     
    y ya esta audio HDMI funcionando
     

     

     
    solo un problema no puedo controlar el audio desde el pc, pero eso es lo de menos.....
     
     
     
    por curiosidad me sabríais decir si se puede hacer funcionar un multilector de tarjetas (SD,Microsd....) con bluetooth incorporado el bluetooth si que me lo detecta Osx , pero se conecta y se desconecta
    y el lector de tarjetas  no se si funciona , no lo he podido probar por no tener una micros, mañana lo probare , pero no me sale como lector de targetas... sabéis si se puede  hacer funcionar???
    es por saber si merece la pena  perder el tiempo con ello o no.....  y de ser así como hacer que Osx me lo detecte como un lector de tarjetas... 
     
     
    Gracias amigos. y perdonad por las molestias
    DarwinDumper_3.0.3_16.08_02.08.39_iMac14,2_AMI_X64_4152_Sierra_16G29_xavidenia.zip
  3. Like
    XAVIDENIA got a reaction from imjohnjo in [Solucionado] Error con audio de Motherboard y HDMI   
    el problema es que yo solo tengo la gráfica onboard , de todas formas gracias ya me lo están mirando..... 
     
    gracias compi
  4. Like
    XAVIDENIA got a reaction from imjohnjo in [Solucionado] Error con audio de Motherboard y HDMI   
    hola,
    mal he instalado todo según la guía y si me activa todos los controles de audio , pero no saca audio  de ninguna de las formas
  5. Like
    XAVIDENIA got a reaction from imjohnjo in [Solucionado] Error con audio de Motherboard y HDMI   
    Gracias amigo la verdad es que no  instale  OS X siguiendo el método rampage..... pero probare a ver que pasa si ejecuto el Command...
  6. Like
    XAVIDENIA got a reaction from imjohnjo in [Solucionado] Error con audio de Motherboard y HDMI   
    Hola imjohnjo  aver estoy tratando de seguir la guía de http://www.rampagedev.com/downloads/  pero tengo algunas dudas .... tengo que hacer todos los pasos o solo los que me interesan......  lo digo porque en algun paso tengo dudas como por ejemplo:
     
    En el paso 5: Motherboard SSDT Installation es necesario???
     la otra duda es como se el archivo comand que  se corresponde a mi codec de audio?????
  7. Like
    XAVIDENIA got a reaction from Maniac10 in Tutorial para crear kexts (traducido al Español)   
    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:
    “El decidir si prefiere crear una extensión del núcleo” explica cuando es absolutamente necesario crear un kext, junto con alternativas más seguras, más sencillas para los problemas comunes. “La Anatomía de una extensión del kernel” describe los componentes de un paquete kext. “Creación de una extensión del kernel genérico con Xcode” le guía a través de la creación de un kext genérico simple. “Creación de un controlador de dispositivo con Xcode” le guía a través de la creación de una I / O de controlador de dispositivo Kit simple. “Depuración de una extensión del kernel con GDB” e guía a través de la depuración de una extensión del kernel con GDB. “Herramientas de línea de comandos para el análisis de las extensiones del kernel” describe las herramientas de línea de comandos que puede utilizar cuando se trabaja con kexts. “Empaquetar una extensión del kernel para la distribución e instalación” le guía a través del uso de la aplicación Creador paquete para empaquetar su kext. “Propiedades Info.plist para las extensiones del kernel” describe propiedades KEXT específica de información de lista de propiedades de su kext. Veremos también 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:
    Si va a desarrollar un controlador de dispositivo USB o FireWire, I / O Kit proporciona una interfaz para comunicarse con los dispositivos USB y FireWire desde el espacio de usuario. Ver USB Device Interface Guide y FireWire Device Interface Guide. Si está desarrollando una aplicación de fondo persistente que no requiere de permisos del kernel, escribe un daemon. Ver Daemons and Services  y Programming Guide. 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.
    Iniciar Xcode. Elija Archivo> Nuevo> Proyecto. Aparece el panel Nuevo proyecto. 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. En la pantalla que aparece, introduzca MyKext para el nombre del producto, escriba un identificador de la compañía, y haga clic en Siguiente. Elija 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, MyKext.c, que contiene las plantillas de la funciones  Start y Stop para el kext.
    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
    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
    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. 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.
    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
    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. Cambie el valor de la propiedad CFBundleIdentifier utilice su prefijo de espacio único. 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)
    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. Haga clic en el triángulo situado junto a objetivos en el panel Grupos y Archivos. Seleccione el destino MyKext. Seleccione Archivo> Obtener información. “MyKext” se abre la ventana de Tarjeta de información. En la lista de opciones, encontrar Build Arquitectura Sólo Activo y asegúrese de que la casilla de verificación no está marcada. 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).
    Inicie la aplicación Terminal, que se encuentra en /Applications/Utilities. 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.
    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>
    Asegúrese que kextlibs a salido con un estado correcto comprobando la variable de shell. $?. $ echo $?
    0
    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. 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)
    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. 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
    eleccione todas las líneas que definen el diccionario OSBundleLibraries vacío:         <key>OSBundleLibraries</key>
            <dict/>
    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>
    Guarde los cambios seleccionando Archivo> Guardar. 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.
    Iniciar Xcode. Elija Archivo> Nuevo> Proyecto. Aparece el panel Nuevo proyecto. 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. En la pantalla que aparece, introduzca MyDriver para el nombre del producto, escriba un identificador de la compañía, y haga clic en Siguiente. 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.
    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
    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. Cambie el valor de la propiedad CFBundleIdentifier utilizar su prefijo de espacio único. 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
    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.
    Implementar los puntos de entrada del controlador Abrir MyDriver.cpp en la carpeta de origen (Source). El archivo por defecto no contiene ningún código. 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. La función IOLog s el equivalente del núcleo(kernel) de printf para obtener un controlador Kit I / O. Guarde los cambios seleccionando Archivo> Guardar. 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.
    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>
    Asegúrese de que kextlibs ha salido con un estado correcto comprobando la variable de Shell. $?. $ echo $?
    0
    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.” 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
    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. 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. 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. Figura 4  MyKext Info.plist archive como texto Seleccione todas las líneas vacias que definen el diccionario OSBundleLibraries.         <key>OSBundleLibraries</key>
            <dict/>
    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>
    Guarde los cambios seleccionando Archivo> Guardar. 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:
    “Configuración preliminar” “Iniciar GDB y conectar las dos máquinas” “Depurar el Kernel Extension” Configuración preliminar
    Preparar las máquinas
    Preparar las dos máquinas de la siguiente manera: Asegúrese de que las máquinas se están ejecutando la misma versión de OS X Asegúrese de que las máquinas están conectadas a la misma red con sus puertos integrados Ethernet. Asegúrese de que ha iniciado la sesión como administrador en ambas máquinas, lo cual es necesario para utilizar el comando sudo. 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
    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. 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;
    Reconstruir su kext. En la aplicación Terminal, cree una copia de la kext como root: $ sudo cp -R MyDriver.kext /tmp
    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
    Antes de que pueda depurar el kext, primero debe habilitar la depuración del kernel. En el equipo de destino, haga lo siguiente: Inicie la aplicación Terminal. 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.
    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
    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
    Añadir macros específicos del Kernel Debug Kit a la sesión de GDB. (gdb) source /Volumes/KernelDebugKit/kgmacros
    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
    Ahora usted puede le puede decir a GDB que se inserte en el equipo de destino. En el equipo de desarrollo, haga lo siguiente: 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
    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.
    Abrir una segunda ventana de Terminal 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
    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
    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
    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:
    “Establecer permisos para su Kext” “Crear Información del instalador personalizado” “Crear un paquete con PackageMaker” “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.
    Cree un directorio para una copia de su kext en el directorio /tmp como usuario root. % cd /tmp
    % sudo mkdir mykextdir
    Password:
    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/
    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.
    Crear un nuevo archivo en TextEdit. Introduzca el texto de su mensaje de bienvenida. Guarde su mensaje de bienvenida como Welcome.rtf en la carpeta del proyecto de su kext. 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.
    Crear un nuevo archivo en TextEdit. Introduzca el texto de su Léame. Guarde su mensaje de bienvenida como ReadMe.rtf en la carpeta del proyecto de su kext 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.
    Crear un nuevo archivo en TextEdit. Introduzca el texto de su contrato de licencia de software. Guarde su contrato de licencia de software como License.rtf en la carpeta del proyecto kexts. 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.
    Abrir la aplicación PackageMaker , situado en /Developer/Applications/Utilities. Aparecerá la ventana principal con una hoja de Instalar propiedades.
    Introduzca  com.MyCompany en el campo Organización, y seleccione OS X v10.5 Leopard como el objetivo mínimo. Haga clic en Aceptar.  
    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)
    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ó. 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. 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. 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.
    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. 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.
    Haga clic en el paquete MyKext en la parte superior izquierda por encima de los contenidos de la vista. Haga clic en la ficha Acciones. Haga clic en el botón Editar para cualquiera Preinstalar acciones o postinstall acciones, dependiendo de lo que desee agregar. Aparecera una hoja. 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. 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.
    Seleccione Proyecto> Construir. Especifique una ubicación de su elección e introducir MyKext.pkg como nombre de archivo.
    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.
    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.
     
  8. Like
    XAVIDENIA got a reaction from Maniac10 in Tutorial para crear kexts (traducido al Español)   
    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:
    “El decidir si prefiere crear una extensión del núcleo” explica cuando es absolutamente necesario crear un kext, junto con alternativas más seguras, más sencillas para los problemas comunes. “La Anatomía de una extensión del kernel” describe los componentes de un paquete kext. “Creación de una extensión del kernel genérico con Xcode” le guía a través de la creación de un kext genérico simple. “Creación de un controlador de dispositivo con Xcode” le guía a través de la creación de una I / O de controlador de dispositivo Kit simple. “Depuración de una extensión del kernel con GDB” e guía a través de la depuración de una extensión del kernel con GDB. “Herramientas de línea de comandos para el análisis de las extensiones del kernel” describe las herramientas de línea de comandos que puede utilizar cuando se trabaja con kexts. “Empaquetar una extensión del kernel para la distribución e instalación” le guía a través del uso de la aplicación Creador paquete para empaquetar su kext. “Propiedades Info.plist para las extensiones del kernel” describe propiedades KEXT específica de información de lista de propiedades de su kext. Veremos también 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:
    Si va a desarrollar un controlador de dispositivo USB o FireWire, I / O Kit proporciona una interfaz para comunicarse con los dispositivos USB y FireWire desde el espacio de usuario. Ver USB Device Interface Guide y FireWire Device Interface Guide. Si está desarrollando una aplicación de fondo persistente que no requiere de permisos del kernel, escribe un daemon. Ver Daemons and Services  y Programming Guide. 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.
    Iniciar Xcode. Elija Archivo> Nuevo> Proyecto. Aparece el panel Nuevo proyecto. 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. En la pantalla que aparece, introduzca MyKext para el nombre del producto, escriba un identificador de la compañía, y haga clic en Siguiente. Elija 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, MyKext.c, que contiene las plantillas de la funciones  Start y Stop para el kext.
    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
    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
    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. 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.
    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
    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. Cambie el valor de la propiedad CFBundleIdentifier utilice su prefijo de espacio único. 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)
    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. Haga clic en el triángulo situado junto a objetivos en el panel Grupos y Archivos. Seleccione el destino MyKext. Seleccione Archivo> Obtener información. “MyKext” se abre la ventana de Tarjeta de información. En la lista de opciones, encontrar Build Arquitectura Sólo Activo y asegúrese de que la casilla de verificación no está marcada. 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).
    Inicie la aplicación Terminal, que se encuentra en /Applications/Utilities. 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.
    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>
    Asegúrese que kextlibs a salido con un estado correcto comprobando la variable de shell. $?. $ echo $?
    0
    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. 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)
    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. 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
    eleccione todas las líneas que definen el diccionario OSBundleLibraries vacío:         <key>OSBundleLibraries</key>
            <dict/>
    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>
    Guarde los cambios seleccionando Archivo> Guardar. 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.
    Iniciar Xcode. Elija Archivo> Nuevo> Proyecto. Aparece el panel Nuevo proyecto. 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. En la pantalla que aparece, introduzca MyDriver para el nombre del producto, escriba un identificador de la compañía, y haga clic en Siguiente. 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.
    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
    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. Cambie el valor de la propiedad CFBundleIdentifier utilizar su prefijo de espacio único. 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
    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.
    Implementar los puntos de entrada del controlador Abrir MyDriver.cpp en la carpeta de origen (Source). El archivo por defecto no contiene ningún código. 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. La función IOLog s el equivalente del núcleo(kernel) de printf para obtener un controlador Kit I / O. Guarde los cambios seleccionando Archivo> Guardar. 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.
    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>
    Asegúrese de que kextlibs ha salido con un estado correcto comprobando la variable de Shell. $?. $ echo $?
    0
    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.” 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
    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. 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. 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. Figura 4  MyKext Info.plist archive como texto Seleccione todas las líneas vacias que definen el diccionario OSBundleLibraries.         <key>OSBundleLibraries</key>
            <dict/>
    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>
    Guarde los cambios seleccionando Archivo> Guardar. 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:
    “Configuración preliminar” “Iniciar GDB y conectar las dos máquinas” “Depurar el Kernel Extension” Configuración preliminar
    Preparar las máquinas
    Preparar las dos máquinas de la siguiente manera: Asegúrese de que las máquinas se están ejecutando la misma versión de OS X Asegúrese de que las máquinas están conectadas a la misma red con sus puertos integrados Ethernet. Asegúrese de que ha iniciado la sesión como administrador en ambas máquinas, lo cual es necesario para utilizar el comando sudo. 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
    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. 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;
    Reconstruir su kext. En la aplicación Terminal, cree una copia de la kext como root: $ sudo cp -R MyDriver.kext /tmp
    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
    Antes de que pueda depurar el kext, primero debe habilitar la depuración del kernel. En el equipo de destino, haga lo siguiente: Inicie la aplicación Terminal. 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.
    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
    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
    Añadir macros específicos del Kernel Debug Kit a la sesión de GDB. (gdb) source /Volumes/KernelDebugKit/kgmacros
    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
    Ahora usted puede le puede decir a GDB que se inserte en el equipo de destino. En el equipo de desarrollo, haga lo siguiente: 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
    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.
    Abrir una segunda ventana de Terminal 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
    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
    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
    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:
    “Establecer permisos para su Kext” “Crear Información del instalador personalizado” “Crear un paquete con PackageMaker” “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.
    Cree un directorio para una copia de su kext en el directorio /tmp como usuario root. % cd /tmp
    % sudo mkdir mykextdir
    Password:
    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/
    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.
    Crear un nuevo archivo en TextEdit. Introduzca el texto de su mensaje de bienvenida. Guarde su mensaje de bienvenida como Welcome.rtf en la carpeta del proyecto de su kext. 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.
    Crear un nuevo archivo en TextEdit. Introduzca el texto de su Léame. Guarde su mensaje de bienvenida como ReadMe.rtf en la carpeta del proyecto de su kext 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.
    Crear un nuevo archivo en TextEdit. Introduzca el texto de su contrato de licencia de software. Guarde su contrato de licencia de software como License.rtf en la carpeta del proyecto kexts. 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.
    Abrir la aplicación PackageMaker , situado en /Developer/Applications/Utilities. Aparecerá la ventana principal con una hoja de Instalar propiedades.
    Introduzca  com.MyCompany en el campo Organización, y seleccione OS X v10.5 Leopard como el objetivo mínimo. Haga clic en Aceptar.  
    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)
    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ó. 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. 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. 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.
    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. 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.
    Haga clic en el paquete MyKext en la parte superior izquierda por encima de los contenidos de la vista. Haga clic en la ficha Acciones. Haga clic en el botón Editar para cualquiera Preinstalar acciones o postinstall acciones, dependiendo de lo que desee agregar. Aparecera una hoja. 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. 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.
    Seleccione Proyecto> Construir. Especifique una ubicación de su elección e introducir MyKext.pkg como nombre de archivo.
    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.
    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.
     
  9. Like
    XAVIDENIA got a reaction from Java Lava in Instalador Mavericks no quiere arrancar con clover   
    Hola Java Lava...... desconozco cual pueda ser tu problema.... si te puedo decir que en una ocasion me volvi loco tratando de instalar el OS X Mavericks en un pc identico al mio y no habia forma de instalarlo me daba error al cargar.... configure la bios igual que la mia , elimine el hardware que creia que me podia dar conflicto como targetas wifi internas y nada..... y despues de semanas dando vueltas por ahi y buscando por las webs......
    di con un post  que aconsejaba cambiar la fuente de alimentacion, yo ya lo habia dado por imposible, creia que era la placa base que tenia algun problema.... asi que perdido por perdido decidi cambiar la fuente de alimentacion  y sopresa me arranco el instalador a la primera y lo puede instalar........
     
    por otro lado yo jamas he usado el clover para arrancar el instalador de OS X Mavericks......
    sino que cogia la imagen.dmg  del Mavericks la abria y me montaba el instalador yo mismo en un usb... creo que habia un tutorial por aqui que decia como hacerlo paso a paso. el procedimiento incluia algun paso en terminal......
     y asi el instalador usb arracaba directamente desde el pc sin ningun bootloader externo.....
    una vez instalado le instalaba el clover y se lo configuraba y listo ya arrancaba por si mismo..... el resto era pulir el OS y los devices....
    si cuando llegue a casa tengo la direccion del post de como montar la imagen en usb manualmente te la paso, por si te sirve de algo.....
     
    saludos amigo y espero te sirva de algo lo que te he comentado
  10. Like
    XAVIDENIA got a reaction from Maniac10 in ¿Como añadir entrada personalizada en Clover?   
    Si no has encontrado solucion.... te la doy ahora mismo  para empezar en antecesor de W10 es W8 y W8.1 para tu informacion estos sistemas operativos cuando se instalan , se instala en sistema de particion de disco GPT(UEFI) , nunca he probado a instalarlo en mbr , pq siendo un sistema que por defecto se instala en GPT(UEFI) es tonteria instalarlo en mbr y perder todo lo bueno del UEFI.... una vez instalado en uefi tienes y montado el clover en osx, con el darwin Dumper haces un dump de todo , te saladran todos los disco que tiene el pc y cada una de las particiones de cada disco.. seleccionas la particion uefi de w10 y copias su uuid.
    luego te vas a osx , abres clover buscas la pestaña donde se editan las entradas  y añades el uuid de esa particion debe de ser algo asi HD1,(XXXXXXX;XXXXX;XXXXX:XXXXX)
    si no recuerdo mal hay un post por aqui donde lo explico paso por paso y con algunas imagens...
  11. Like
    XAVIDENIA got a reaction from Maniac10 in Perdida doble booteo   
    saludos Chuzz no se quien te dio dicha información ........ pero desde luedo hay un post muy bien detallado sobre como hacer un cuádruple booteo por medio de clover
    un post que yo mismo escribí  y que conseguí hacer el cuádruple booteo y la configuración de dicho booteo en el clover gracias a otro forero de aquí que se llama Maniac10
     
    te paso el enlace por si te interesa o necesitas aclarar alguna duda......
     
    http://www.insanelymac.com/forum/topic/282714-bienvenido-clover/page-7
     
    por cierto en cuanto a tu problema sobre instalar windows sin desconectar el disco de osx , no se quien te dio la solución pero lo explico detalladamente en este post
     
    la solución es correcta reinstalar el clover bootloader,(si puede acceder a la partición efi y hacer un copia del config.plist del clover, te ahorraras tiempo de configuración de l clover) aunque yo soy partidario de reinstalar todo el osx...... después de reinstalar el clover como digo en mi post entrar en osx y configurar  el clover o cambiarle el config.plit y cargaselo para que arranque osx y ya por ultimo conectar el disco de windows.... reiniciar acceder a bios y poner el primer disco en arrancar el que tiene el osx instalado y listo, problema solucionado.....
     
    ten encuenta que cada vez que reinstalas un SO  ese SO se queda grabado en bios como que es el primero en arrancar .....
     
    saludos
  12. Like
    XAVIDENIA got a reaction from Maniac10 in Tutorial para crear kexts (traducido al Español)   
    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:
    “El decidir si prefiere crear una extensión del núcleo” explica cuando es absolutamente necesario crear un kext, junto con alternativas más seguras, más sencillas para los problemas comunes. “La Anatomía de una extensión del kernel” describe los componentes de un paquete kext. “Creación de una extensión del kernel genérico con Xcode” le guía a través de la creación de un kext genérico simple. “Creación de un controlador de dispositivo con Xcode” le guía a través de la creación de una I / O de controlador de dispositivo Kit simple. “Depuración de una extensión del kernel con GDB” e guía a través de la depuración de una extensión del kernel con GDB. “Herramientas de línea de comandos para el análisis de las extensiones del kernel” describe las herramientas de línea de comandos que puede utilizar cuando se trabaja con kexts. “Empaquetar una extensión del kernel para la distribución e instalación” le guía a través del uso de la aplicación Creador paquete para empaquetar su kext. “Propiedades Info.plist para las extensiones del kernel” describe propiedades KEXT específica de información de lista de propiedades de su kext. Veremos también 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:
    Si va a desarrollar un controlador de dispositivo USB o FireWire, I / O Kit proporciona una interfaz para comunicarse con los dispositivos USB y FireWire desde el espacio de usuario. Ver USB Device Interface Guide y FireWire Device Interface Guide. Si está desarrollando una aplicación de fondo persistente que no requiere de permisos del kernel, escribe un daemon. Ver Daemons and Services  y Programming Guide. 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.
    Iniciar Xcode. Elija Archivo> Nuevo> Proyecto. Aparece el panel Nuevo proyecto. 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. En la pantalla que aparece, introduzca MyKext para el nombre del producto, escriba un identificador de la compañía, y haga clic en Siguiente. Elija 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, MyKext.c, que contiene las plantillas de la funciones  Start y Stop para el kext.
    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
    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
    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. 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.
    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
    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. Cambie el valor de la propiedad CFBundleIdentifier utilice su prefijo de espacio único. 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)
    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. Haga clic en el triángulo situado junto a objetivos en el panel Grupos y Archivos. Seleccione el destino MyKext. Seleccione Archivo> Obtener información. “MyKext” se abre la ventana de Tarjeta de información. En la lista de opciones, encontrar Build Arquitectura Sólo Activo y asegúrese de que la casilla de verificación no está marcada. 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).
    Inicie la aplicación Terminal, que se encuentra en /Applications/Utilities. 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.
    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>
    Asegúrese que kextlibs a salido con un estado correcto comprobando la variable de shell. $?. $ echo $?
    0
    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. 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)
    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. 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
    eleccione todas las líneas que definen el diccionario OSBundleLibraries vacío:         <key>OSBundleLibraries</key>
            <dict/>
    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>
    Guarde los cambios seleccionando Archivo> Guardar. 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.
    Iniciar Xcode. Elija Archivo> Nuevo> Proyecto. Aparece el panel Nuevo proyecto. 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. En la pantalla que aparece, introduzca MyDriver para el nombre del producto, escriba un identificador de la compañía, y haga clic en Siguiente. 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.
    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
    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. Cambie el valor de la propiedad CFBundleIdentifier utilizar su prefijo de espacio único. 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
    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.
    Implementar los puntos de entrada del controlador Abrir MyDriver.cpp en la carpeta de origen (Source). El archivo por defecto no contiene ningún código. 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. La función IOLog s el equivalente del núcleo(kernel) de printf para obtener un controlador Kit I / O. Guarde los cambios seleccionando Archivo> Guardar. 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.
    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>
    Asegúrese de que kextlibs ha salido con un estado correcto comprobando la variable de Shell. $?. $ echo $?
    0
    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.” 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
    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. 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. 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. Figura 4  MyKext Info.plist archive como texto Seleccione todas las líneas vacias que definen el diccionario OSBundleLibraries.         <key>OSBundleLibraries</key>
            <dict/>
    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>
    Guarde los cambios seleccionando Archivo> Guardar. 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:
    “Configuración preliminar” “Iniciar GDB y conectar las dos máquinas” “Depurar el Kernel Extension” Configuración preliminar
    Preparar las máquinas
    Preparar las dos máquinas de la siguiente manera: Asegúrese de que las máquinas se están ejecutando la misma versión de OS X Asegúrese de que las máquinas están conectadas a la misma red con sus puertos integrados Ethernet. Asegúrese de que ha iniciado la sesión como administrador en ambas máquinas, lo cual es necesario para utilizar el comando sudo. 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
    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. 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;
    Reconstruir su kext. En la aplicación Terminal, cree una copia de la kext como root: $ sudo cp -R MyDriver.kext /tmp
    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
    Antes de que pueda depurar el kext, primero debe habilitar la depuración del kernel. En el equipo de destino, haga lo siguiente: Inicie la aplicación Terminal. 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.
    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
    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
    Añadir macros específicos del Kernel Debug Kit a la sesión de GDB. (gdb) source /Volumes/KernelDebugKit/kgmacros
    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
    Ahora usted puede le puede decir a GDB que se inserte en el equipo de destino. En el equipo de desarrollo, haga lo siguiente: 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
    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.
    Abrir una segunda ventana de Terminal 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
    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
    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
    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:
    “Establecer permisos para su Kext” “Crear Información del instalador personalizado” “Crear un paquete con PackageMaker” “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.
    Cree un directorio para una copia de su kext en el directorio /tmp como usuario root. % cd /tmp
    % sudo mkdir mykextdir
    Password:
    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/
    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.
    Crear un nuevo archivo en TextEdit. Introduzca el texto de su mensaje de bienvenida. Guarde su mensaje de bienvenida como Welcome.rtf en la carpeta del proyecto de su kext. 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.
    Crear un nuevo archivo en TextEdit. Introduzca el texto de su Léame. Guarde su mensaje de bienvenida como ReadMe.rtf en la carpeta del proyecto de su kext 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.
    Crear un nuevo archivo en TextEdit. Introduzca el texto de su contrato de licencia de software. Guarde su contrato de licencia de software como License.rtf en la carpeta del proyecto kexts. 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.
    Abrir la aplicación PackageMaker , situado en /Developer/Applications/Utilities. Aparecerá la ventana principal con una hoja de Instalar propiedades.
    Introduzca  com.MyCompany en el campo Organización, y seleccione OS X v10.5 Leopard como el objetivo mínimo. Haga clic en Aceptar.  
    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)
    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ó. 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. 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. 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.
    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. 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.
    Haga clic en el paquete MyKext en la parte superior izquierda por encima de los contenidos de la vista. Haga clic en la ficha Acciones. Haga clic en el botón Editar para cualquiera Preinstalar acciones o postinstall acciones, dependiendo de lo que desee agregar. Aparecera una hoja. 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. 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.
    Seleccione Proyecto> Construir. Especifique una ubicación de su elección e introducir MyKext.pkg como nombre de archivo.
    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.
    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.
     
  13. Like
    XAVIDENIA got a reaction from Maniac10 in Tutorial para crear kexts (traducido al Español)   
    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:
    “El decidir si prefiere crear una extensión del núcleo” explica cuando es absolutamente necesario crear un kext, junto con alternativas más seguras, más sencillas para los problemas comunes. “La Anatomía de una extensión del kernel” describe los componentes de un paquete kext. “Creación de una extensión del kernel genérico con Xcode” le guía a través de la creación de un kext genérico simple. “Creación de un controlador de dispositivo con Xcode” le guía a través de la creación de una I / O de controlador de dispositivo Kit simple. “Depuración de una extensión del kernel con GDB” e guía a través de la depuración de una extensión del kernel con GDB. “Herramientas de línea de comandos para el análisis de las extensiones del kernel” describe las herramientas de línea de comandos que puede utilizar cuando se trabaja con kexts. “Empaquetar una extensión del kernel para la distribución e instalación” le guía a través del uso de la aplicación Creador paquete para empaquetar su kext. “Propiedades Info.plist para las extensiones del kernel” describe propiedades KEXT específica de información de lista de propiedades de su kext. Veremos también 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:
    Si va a desarrollar un controlador de dispositivo USB o FireWire, I / O Kit proporciona una interfaz para comunicarse con los dispositivos USB y FireWire desde el espacio de usuario. Ver USB Device Interface Guide y FireWire Device Interface Guide. Si está desarrollando una aplicación de fondo persistente que no requiere de permisos del kernel, escribe un daemon. Ver Daemons and Services  y Programming Guide. 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.
    Iniciar Xcode. Elija Archivo> Nuevo> Proyecto. Aparece el panel Nuevo proyecto. 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. En la pantalla que aparece, introduzca MyKext para el nombre del producto, escriba un identificador de la compañía, y haga clic en Siguiente. Elija 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, MyKext.c, que contiene las plantillas de la funciones  Start y Stop para el kext.
    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
    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
    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. 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.
    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
    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. Cambie el valor de la propiedad CFBundleIdentifier utilice su prefijo de espacio único. 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)
    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. Haga clic en el triángulo situado junto a objetivos en el panel Grupos y Archivos. Seleccione el destino MyKext. Seleccione Archivo> Obtener información. “MyKext” se abre la ventana de Tarjeta de información. En la lista de opciones, encontrar Build Arquitectura Sólo Activo y asegúrese de que la casilla de verificación no está marcada. 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).
    Inicie la aplicación Terminal, que se encuentra en /Applications/Utilities. 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.
    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>
    Asegúrese que kextlibs a salido con un estado correcto comprobando la variable de shell. $?. $ echo $?
    0
    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. 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)
    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. 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
    eleccione todas las líneas que definen el diccionario OSBundleLibraries vacío:         <key>OSBundleLibraries</key>
            <dict/>
    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>
    Guarde los cambios seleccionando Archivo> Guardar. 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.
    Iniciar Xcode. Elija Archivo> Nuevo> Proyecto. Aparece el panel Nuevo proyecto. 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. En la pantalla que aparece, introduzca MyDriver para el nombre del producto, escriba un identificador de la compañía, y haga clic en Siguiente. 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.
    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
    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. Cambie el valor de la propiedad CFBundleIdentifier utilizar su prefijo de espacio único. 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
    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.
    Implementar los puntos de entrada del controlador Abrir MyDriver.cpp en la carpeta de origen (Source). El archivo por defecto no contiene ningún código. 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. La función IOLog s el equivalente del núcleo(kernel) de printf para obtener un controlador Kit I / O. Guarde los cambios seleccionando Archivo> Guardar. 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.
    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>
    Asegúrese de que kextlibs ha salido con un estado correcto comprobando la variable de Shell. $?. $ echo $?
    0
    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.” 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
    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. 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. 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. Figura 4  MyKext Info.plist archive como texto Seleccione todas las líneas vacias que definen el diccionario OSBundleLibraries.         <key>OSBundleLibraries</key>
            <dict/>
    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>
    Guarde los cambios seleccionando Archivo> Guardar. 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:
    “Configuración preliminar” “Iniciar GDB y conectar las dos máquinas” “Depurar el Kernel Extension” Configuración preliminar
    Preparar las máquinas
    Preparar las dos máquinas de la siguiente manera: Asegúrese de que las máquinas se están ejecutando la misma versión de OS X Asegúrese de que las máquinas están conectadas a la misma red con sus puertos integrados Ethernet. Asegúrese de que ha iniciado la sesión como administrador en ambas máquinas, lo cual es necesario para utilizar el comando sudo. 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
    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. 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;
    Reconstruir su kext. En la aplicación Terminal, cree una copia de la kext como root: $ sudo cp -R MyDriver.kext /tmp
    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
    Antes de que pueda depurar el kext, primero debe habilitar la depuración del kernel. En el equipo de destino, haga lo siguiente: Inicie la aplicación Terminal. 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.
    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
    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
    Añadir macros específicos del Kernel Debug Kit a la sesión de GDB. (gdb) source /Volumes/KernelDebugKit/kgmacros
    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
    Ahora usted puede le puede decir a GDB que se inserte en el equipo de destino. En el equipo de desarrollo, haga lo siguiente: 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
    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.
    Abrir una segunda ventana de Terminal 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
    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
    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
    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:
    “Establecer permisos para su Kext” “Crear Información del instalador personalizado” “Crear un paquete con PackageMaker” “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.
    Cree un directorio para una copia de su kext en el directorio /tmp como usuario root. % cd /tmp
    % sudo mkdir mykextdir
    Password:
    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/
    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.
    Crear un nuevo archivo en TextEdit. Introduzca el texto de su mensaje de bienvenida. Guarde su mensaje de bienvenida como Welcome.rtf en la carpeta del proyecto de su kext. 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.
    Crear un nuevo archivo en TextEdit. Introduzca el texto de su Léame. Guarde su mensaje de bienvenida como ReadMe.rtf en la carpeta del proyecto de su kext 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.
    Crear un nuevo archivo en TextEdit. Introduzca el texto de su contrato de licencia de software. Guarde su contrato de licencia de software como License.rtf en la carpeta del proyecto kexts. 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.
    Abrir la aplicación PackageMaker , situado en /Developer/Applications/Utilities. Aparecerá la ventana principal con una hoja de Instalar propiedades.
    Introduzca  com.MyCompany en el campo Organización, y seleccione OS X v10.5 Leopard como el objetivo mínimo. Haga clic en Aceptar.  
    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)
    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ó. 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. 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. 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.
    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. 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.
    Haga clic en el paquete MyKext en la parte superior izquierda por encima de los contenidos de la vista. Haga clic en la ficha Acciones. Haga clic en el botón Editar para cualquiera Preinstalar acciones o postinstall acciones, dependiendo de lo que desee agregar. Aparecera una hoja. 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. 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.
    Seleccione Proyecto> Construir. Especifique una ubicación de su elección e introducir MyKext.pkg como nombre de archivo.
    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.
    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.
     
  14. Like
    XAVIDENIA got a reaction from E=MC2 in Mavericks sin Audio mediante Clover.   
    aver yo tb estoy liado con lo de audio en haswell hasta ahora no he tenido la forma de activar el audio hdmi ya que este audio va completamente separado del realteck alc xxx, en mi caso alc898 
     
    el audio hdmi va junto con la grafica y con appleinteazulframebuffer.kext
    el resto a audi jacks delanteros y traseros va por medio del alc xxx
    he conseguido hacer funcionar el audio a lcxxx en mavericks pero con mucho ruido de fondo........
    no te aconsejo de desisntales el hda.kext, solo instalale un hdadisabler.kext para que applehda.kext se quede deshabilitado, asi no perdemos el applehda original para futuros acontecimientos.... y nos funcionara el vodoohdaxxx.kext los dos juntos no funcionan......
     instalale el voodoohda 2.8.5.kext(basado en toleda)tanto el kext como panel de preferencias o en su defecto el voodoohda que sea para tu alc892 , hay un paquete pkg del voodoohda que te lo instala todo automáticamente,solo tiene que darle permisos...........
     creo que el voodooohda2.8.5.kext tambien soporta los chips alc892 pero abría que cersionarse en la web....
     
    prueba seguro que te funciona el audio alc xxx....
     
    yo sigo ala espera de que me conteste java lava pues el tiene el mismo procesador que yo y  una placa base de la misma marca y chipset que yo con el audio hdmi funcionando, según  puede leer en un post suyo modifico el appleintelazulframebuffer.kext  supongo que por eso tendrá  audio hdmi en cuanto me pase una copia  de dicho kext con la que pueda comparar mi appleintelazulframebuffer.kext y ver en que varian..... y hacer un post mas simple que el de toleda sobre como habilitar audio tanto hdmi como alcxxx  en dispositivos haswell.......
     
    espero que te haya sirva de ayuda todo lo que te estoy exponiendo aquí
     
    los problemas que dices que tienes de energía no se por donde vendrán pero tienes un chipset similar al mío  el tuyo es z87mx y el mío z87x  y en mi placa no hace nada de lo que tu dices , no se reinicia ....... habría que ver si tu bios es uefi,legacy o híbrida y si tienes osx instalado en uefi o en legacy
     
    la diferencia es muy grande en uefi osx reconoce muchos mas drivers que en lagacy
     
    por ejemplo reconoce el powermanagement y parchea el kext automaticamente  y se solucionan muchos problemas de energia
    para  los problemas de energía intenta leerte el FAQ de Clover hay algunas soluciones para reinicios.....
     
    puede que esta pagina sea de tu interés.....http://clover-wiki.zetam.org/es/Configuracion/es.ACPI
     
    como por ejemplo los apartados ResetAddress and ResetValue
    saludos
  15. Like
    XAVIDENIA got a reaction from E=MC2 in Mavericks sin Audio mediante Clover.   
    aver yo tb estoy liado con lo de audio en haswell hasta ahora no he tenido la forma de activar el audio hdmi ya que este audio va completamente separado del realteck alc xxx, en mi caso alc898 
     
    el audio hdmi va junto con la grafica y con appleinteazulframebuffer.kext
    el resto a audi jacks delanteros y traseros va por medio del alc xxx
    he conseguido hacer funcionar el audio a lcxxx en mavericks pero con mucho ruido de fondo........
    no te aconsejo de desisntales el hda.kext, solo instalale un hdadisabler.kext para que applehda.kext se quede deshabilitado, asi no perdemos el applehda original para futuros acontecimientos.... y nos funcionara el vodoohdaxxx.kext los dos juntos no funcionan......
     instalale el voodoohda 2.8.5.kext(basado en toleda)tanto el kext como panel de preferencias o en su defecto el voodoohda que sea para tu alc892 , hay un paquete pkg del voodoohda que te lo instala todo automáticamente,solo tiene que darle permisos...........
     creo que el voodooohda2.8.5.kext tambien soporta los chips alc892 pero abría que cersionarse en la web....
     
    prueba seguro que te funciona el audio alc xxx....
     
    yo sigo ala espera de que me conteste java lava pues el tiene el mismo procesador que yo y  una placa base de la misma marca y chipset que yo con el audio hdmi funcionando, según  puede leer en un post suyo modifico el appleintelazulframebuffer.kext  supongo que por eso tendrá  audio hdmi en cuanto me pase una copia  de dicho kext con la que pueda comparar mi appleintelazulframebuffer.kext y ver en que varian..... y hacer un post mas simple que el de toleda sobre como habilitar audio tanto hdmi como alcxxx  en dispositivos haswell.......
     
    espero que te haya sirva de ayuda todo lo que te estoy exponiendo aquí
     
    los problemas que dices que tienes de energía no se por donde vendrán pero tienes un chipset similar al mío  el tuyo es z87mx y el mío z87x  y en mi placa no hace nada de lo que tu dices , no se reinicia ....... habría que ver si tu bios es uefi,legacy o híbrida y si tienes osx instalado en uefi o en legacy
     
    la diferencia es muy grande en uefi osx reconoce muchos mas drivers que en lagacy
     
    por ejemplo reconoce el powermanagement y parchea el kext automaticamente  y se solucionan muchos problemas de energia
    para  los problemas de energía intenta leerte el FAQ de Clover hay algunas soluciones para reinicios.....
     
    puede que esta pagina sea de tu interés.....http://clover-wiki.zetam.org/es/Configuracion/es.ACPI
     
    como por ejemplo los apartados ResetAddress and ResetValue
    saludos
  16. Like
    XAVIDENIA got a reaction from Maniac10 in Audio Mavericks: HDMI - ALCXXX - AppleHDA   
    Mavericks: HDMI Audio - AppleHDA
    La mayoría de los códecs de audio / La mayoría de los sistemas de gráficos
     
    Audio Mavericks HDMI es compatible con Intel HD3K/HD4K/HD4600, AMD HD5xxx/HD6xxx/HD7xxx, Nvidia 4xx/5xx/6xx/7xx, Intel / AMD y configuraciones de gráficos Intel / Nvidia. Esta guía proporciona los archivos y las instrucciones para habilitar audio AppleHDA.kext HDMI nativo.
     
    Cambio de registro
    v1.1 - 3/5/2014 - Clover HDMI audio
    v1.0 - 10/23/13 - Mavericks Release Mavericks / Nueva funciónAMD HD7xxx HDMI audio soportado Versiones de OS X SoportadasMavericks: 10.9 y posteriores Requerimientos S/L/E/AppleHDA.kext AppleHDA.kext Nativo en S/L/E /No onboard audio (usar OS X combo update para restaurar AppleHDA.kext nativo) Realtek ALC AppleHDA.kext (885, 887, 888, 889, 892, 898, 1150) Cualquier parcheado Mountain Lion AppleHDA_v2.5.2 y más reciente Graphicas Intel HD Graphics (1ª generation y anteriores , no soportadas) HD5K/HD4600 (Necesario editar Azul framebuffer y AppleHDA edits required, patches disponibles , ver 1. 8 Series HDMI Audio, abajo) HD4K (Edicion Capri framebuffer , ver 2. UEFI HDMI Audio) HD3K ( Edicion SNB framebuffer , ver 4. HD3000/6 Series HDMI Audio) AMD HD5xxx/HD6xxx/HD7xxx AppleHDAController y AMD50000Controller/MD60000Controller/MD60000Controller pueder ser necesario editarlos, ver Editing custom personalities for ATI Radeon HD[45]xxx - ATi - InsanelyMac Forum Nvidia 4xx/5xx/6xx/7xx GTS450, GTX550ti, GTX 560ti no soportados nativamente Placas Base Intel 8 Series - Z87, H87, B85 7 Series - Z77, H77, B75 6 Series - Z68, P67, H67, H61 5 Series - P55, H55 Antes de empezar OS X no proporciona controles de audio HDMI (Sin volumen, sin mute, sin balance, etc.) El Dispositivo HDMI conectado(TV, receptor, etc.) ofrece todas y cada una de la opciones de control de audio Elimine HDAEnabler1.kext o HDAEnabler2.kext de S/L/E (si exiten) Elimine cualquier inyeccion de (Extra/org.chameleon.Boot.plist, Clover/config.plist) Herramientas MaciASL http://maciasl.sourceforge.net/ DCPIManager http://sourceforge.n...ts/dpcimanager/ IORegistryExplorer (IOReg) - Note: current version saves corrupt files. Select View Raw audio_ALCInjection/IORegistryExplorer_v2.1.zip at master · toleda/audio_ALCInjection Mavericks HDMI Audio Clover HDMI audio (dsdt or ssdt or Clover) - toleda/audio_CloverHDMI 8 Series HDMI Audio (dsdt or ssdt) -Desktop toleda/audio_hdmi_8series [Guide]-Haswell-hdmi_audio_(dsdt_or_ssdt)_v1.2.pdf UEFI HDMI Audio (dsdt or ssdt) - Desktop/Laptop/Intel NUC toleda/audio_hdmi_uefi [Guide]-UEFI-hdmi_audio_dsdt_edits_v2.1.pdf HD4000/7 Series MB HDMI Audio (dsdt) - Desktop/Laptop/Intel NUC toleda/audio_hdmi_hd4000 [Guide]-HD4000-hdmi_audio_dsdt_edits_v1.3.pdf HD3000/6 Series MB HDMI Audio (dsdt or ssdt) - Desktop toleda/audio_hdmi_hd3000 [Guide]-HD4000-hdmi_audio_dsdt_edits_v1.3.pdf BIOS (Mavericks HDMI audio same as Mountain Lion HDMI audio) 5 Series MB HDMI Audio dsdt edits - Desktop toleda/audio_hdmi_5series [Guide]-5_series-hdmi_audio_dsdt_edits_v1.1.pdf BIOS (Mavericks HDMI audio same as Mountain Lion HDMI audio) Casos especiales (no hay soporte SSDT HDMI Audio) Procesador HD3000 en Placas Base de la serie 7 , ver 4. HD3000/6 Series MB Procesador HD4000 en Placas Base de la serie 6 , ver 3. HD4000/7 Series MB Placa Base x79 , ver 5. 5 Series Motherboard MB Instalación - Dsdt HDMI audio editado MaciASL, ver Herramientas, 1. dsdt (no hay errores de compilacion) Patch Compilar Guardar Instalar Reconstruir kernel cache, ver Herramientas, 2. Reiniciar Verificar Instalación - Ssdt HDMI audio(Disponible para algunas configuraciones) Descargar Instalar Añadir boot flag DropSSDT/DropOem Reconstruir kernel cache, ver Herramientas, 2. Reiniciar Verificar Solución de problemas Verificar que el dispositivo HDMI esta conectado System Information/Graphics/Display/HDMI device name/Television/Yes Verificar Extra/dsdt.aml es archivo .aml editado Ejecutar IOReg/Verificar Dispositivos(PEGP, GFX0, HDAU, HDEF y IGPU) Dispositivo (IGPU) puede no estar presente si HD3K/HD4K Graphicos no esta habilitada Dispositivo (GFX0) y Dispositivo (HDAU) pueden no estar presentes si no hay gráficas dedicadas instaladas Reporte de problemas (Subir a este hilo adjuntando la información requerida) Placa Base/Version de BIOS /procesador/graphica/ y version de OS X Procedimiento/Guia Usada dsdt/native (.dsl) dsdt/editado (.dsl) copia de IOReg/Selecione Raw Data audio_ALCInjection/IORegistryExplorer_v2.1.zip at master · toleda/audio_ALCInjection Creditos:
    PikeRAlpha Haswell HDAU solution | Pike's Universum
    bcc9 http://www.insanelymac.com/forum/top...ort/?p=1934889, Post #11
    VCH888: ALC889A, Gigabyte (Intel): now having a working front mic - Page 38 - Sound - InsanelyMac Forum
    Maniac10, The Real Deal, aplIIc and 5 others like this Like This  
    Un post muy bonito pero por mucho que he intentado hacer funcionar el audio HDMI en OS X Mavericks , no ha habido forma de conseguirlo....... alguien lo ha intentado con éxito?????
     
    por cierto Maniac10 si ves este post quizás tu puedas decirme como habilitar en audio HDMI atraves del Clover , pues tb esta esa opción , lo que pasa es que no lo acabo de entender y tengo miedo de joder la instalación, quizás se podría probar con un Clover instalado en pendrive???.....
  17. Like
    XAVIDENIA got a reaction from Maniac10 in Audio Mavericks: HDMI - ALCXXX - AppleHDA   
    Mavericks: HDMI Audio - AppleHDA
    La mayoría de los códecs de audio / La mayoría de los sistemas de gráficos
     
    Audio Mavericks HDMI es compatible con Intel HD3K/HD4K/HD4600, AMD HD5xxx/HD6xxx/HD7xxx, Nvidia 4xx/5xx/6xx/7xx, Intel / AMD y configuraciones de gráficos Intel / Nvidia. Esta guía proporciona los archivos y las instrucciones para habilitar audio AppleHDA.kext HDMI nativo.
     
    Cambio de registro
    v1.1 - 3/5/2014 - Clover HDMI audio
    v1.0 - 10/23/13 - Mavericks Release Mavericks / Nueva funciónAMD HD7xxx HDMI audio soportado Versiones de OS X SoportadasMavericks: 10.9 y posteriores Requerimientos S/L/E/AppleHDA.kext AppleHDA.kext Nativo en S/L/E /No onboard audio (usar OS X combo update para restaurar AppleHDA.kext nativo) Realtek ALC AppleHDA.kext (885, 887, 888, 889, 892, 898, 1150) Cualquier parcheado Mountain Lion AppleHDA_v2.5.2 y más reciente Graphicas Intel HD Graphics (1ª generation y anteriores , no soportadas) HD5K/HD4600 (Necesario editar Azul framebuffer y AppleHDA edits required, patches disponibles , ver 1. 8 Series HDMI Audio, abajo) HD4K (Edicion Capri framebuffer , ver 2. UEFI HDMI Audio) HD3K ( Edicion SNB framebuffer , ver 4. HD3000/6 Series HDMI Audio) AMD HD5xxx/HD6xxx/HD7xxx AppleHDAController y AMD50000Controller/MD60000Controller/MD60000Controller pueder ser necesario editarlos, ver Editing custom personalities for ATI Radeon HD[45]xxx - ATi - InsanelyMac Forum Nvidia 4xx/5xx/6xx/7xx GTS450, GTX550ti, GTX 560ti no soportados nativamente Placas Base Intel 8 Series - Z87, H87, B85 7 Series - Z77, H77, B75 6 Series - Z68, P67, H67, H61 5 Series - P55, H55 Antes de empezar OS X no proporciona controles de audio HDMI (Sin volumen, sin mute, sin balance, etc.) El Dispositivo HDMI conectado(TV, receptor, etc.) ofrece todas y cada una de la opciones de control de audio Elimine HDAEnabler1.kext o HDAEnabler2.kext de S/L/E (si exiten) Elimine cualquier inyeccion de (Extra/org.chameleon.Boot.plist, Clover/config.plist) Herramientas MaciASL http://maciasl.sourceforge.net/ DCPIManager http://sourceforge.n...ts/dpcimanager/ IORegistryExplorer (IOReg) - Note: current version saves corrupt files. Select View Raw audio_ALCInjection/IORegistryExplorer_v2.1.zip at master · toleda/audio_ALCInjection Mavericks HDMI Audio Clover HDMI audio (dsdt or ssdt or Clover) - toleda/audio_CloverHDMI 8 Series HDMI Audio (dsdt or ssdt) -Desktop toleda/audio_hdmi_8series [Guide]-Haswell-hdmi_audio_(dsdt_or_ssdt)_v1.2.pdf UEFI HDMI Audio (dsdt or ssdt) - Desktop/Laptop/Intel NUC toleda/audio_hdmi_uefi [Guide]-UEFI-hdmi_audio_dsdt_edits_v2.1.pdf HD4000/7 Series MB HDMI Audio (dsdt) - Desktop/Laptop/Intel NUC toleda/audio_hdmi_hd4000 [Guide]-HD4000-hdmi_audio_dsdt_edits_v1.3.pdf HD3000/6 Series MB HDMI Audio (dsdt or ssdt) - Desktop toleda/audio_hdmi_hd3000 [Guide]-HD4000-hdmi_audio_dsdt_edits_v1.3.pdf BIOS (Mavericks HDMI audio same as Mountain Lion HDMI audio) 5 Series MB HDMI Audio dsdt edits - Desktop toleda/audio_hdmi_5series [Guide]-5_series-hdmi_audio_dsdt_edits_v1.1.pdf BIOS (Mavericks HDMI audio same as Mountain Lion HDMI audio) Casos especiales (no hay soporte SSDT HDMI Audio) Procesador HD3000 en Placas Base de la serie 7 , ver 4. HD3000/6 Series MB Procesador HD4000 en Placas Base de la serie 6 , ver 3. HD4000/7 Series MB Placa Base x79 , ver 5. 5 Series Motherboard MB Instalación - Dsdt HDMI audio editado MaciASL, ver Herramientas, 1. dsdt (no hay errores de compilacion) Patch Compilar Guardar Instalar Reconstruir kernel cache, ver Herramientas, 2. Reiniciar Verificar Instalación - Ssdt HDMI audio(Disponible para algunas configuraciones) Descargar Instalar Añadir boot flag DropSSDT/DropOem Reconstruir kernel cache, ver Herramientas, 2. Reiniciar Verificar Solución de problemas Verificar que el dispositivo HDMI esta conectado System Information/Graphics/Display/HDMI device name/Television/Yes Verificar Extra/dsdt.aml es archivo .aml editado Ejecutar IOReg/Verificar Dispositivos(PEGP, GFX0, HDAU, HDEF y IGPU) Dispositivo (IGPU) puede no estar presente si HD3K/HD4K Graphicos no esta habilitada Dispositivo (GFX0) y Dispositivo (HDAU) pueden no estar presentes si no hay gráficas dedicadas instaladas Reporte de problemas (Subir a este hilo adjuntando la información requerida) Placa Base/Version de BIOS /procesador/graphica/ y version de OS X Procedimiento/Guia Usada dsdt/native (.dsl) dsdt/editado (.dsl) copia de IOReg/Selecione Raw Data audio_ALCInjection/IORegistryExplorer_v2.1.zip at master · toleda/audio_ALCInjection Creditos:
    PikeRAlpha Haswell HDAU solution | Pike's Universum
    bcc9 http://www.insanelymac.com/forum/top...ort/?p=1934889, Post #11
    VCH888: ALC889A, Gigabyte (Intel): now having a working front mic - Page 38 - Sound - InsanelyMac Forum
    Maniac10, The Real Deal, aplIIc and 5 others like this Like This  
    Un post muy bonito pero por mucho que he intentado hacer funcionar el audio HDMI en OS X Mavericks , no ha habido forma de conseguirlo....... alguien lo ha intentado con éxito?????
     
    por cierto Maniac10 si ves este post quizás tu puedas decirme como habilitar en audio HDMI atraves del Clover , pues tb esta esa opción , lo que pasa es que no lo acabo de entender y tengo miedo de joder la instalación, quizás se podría probar con un Clover instalado en pendrive???.....
  18. Like
    XAVIDENIA got a reaction from Maniac10 in Bienvenido CLOVER   
    Bueno continuo aver si termino el post.........
     
    Una vez Clover esta instalado y configurado para OS X  y el sistema ya es capaz de arrancar por si mismo sin necesidad de ningún arranque externo....
     Pasamos a conectar todos los discos  a ser posible uno por uno.....
     
     1. conectamos el Disco W7 y arrancamos nos deberia de salir Clover con uno disco mas aparte del de OS X con un nombre como Windows Boot Manager o algo así...
     
     2. apagamos pc 
     
     3. conectamos disco W8 U 8.1 y arrancamos nos deberia de salir Clover con dos discos mas aparte del de OS X con un nombre como Windows Boot Manager
     
     4. apagamos pc
     
     5. conectamos el otro disco el de Linux y arrancamos nos deberia de salir Clover con tres discos mas aparte del de OS X , el de Linux saldría con un nombre como boot from efi grub.efi o algo asi
     
    6. si tenemos algún otro disco como por ejemplo de almacenamiento .... hacemos lo mismo... apagamos pc  conectamos y arrancamos de nuevo....
     
    7. una vez todos los dicos conectados arrancamos y nos saldrán todos los discos (no os preocupéis si os salen mas entradas pues al estar todos los sistemas instalados en UEFI puede que tb os detecte las entradas de las EFI Y recuperación de windows e linux, al igual que la entrada EFI de OS X..... luego las ocultaremos en la configuración de Clover......
     
    8. arrancamos desde OS X 
     
    9. hacemos un dump con el darwin dumper
     
    10. vamos a Applications/DarwinDumperReports/000_2014-05-14_17-14-01_iMac14,2/DarwinDumper_2.9.1_AMI_X64_2652_Mav_xavidenia/BootLog aqui tendremos un archivo txt , lo abrimos
    0:100 0:100 MemLog inited, TSC freq: 3491919770 0:100 0:000 0:100 0:000 Now is 14.5.2014, 15:53:58 (GMT+2047) 0:100 0:000 Starting Clover rev 2652 on American Megatrends EFI 0:100 0:000 SelfDevicePath=PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(1,GPT,C6303D1D-224C-47D4-9C4C-AE489C0AE0D1,0x28,0x64000) @6FE6FF98 0:100 0:000 SelfDirPath = \EFI\BOOT 0:100 0:000 Total Memory Slots Count = 4 0:100 0:000 Type 17 Index = 0 0:100 0:000 SmbiosTable.Type17->Speed = 1600 0:100 0:000 SmbiosTable.Type17->Size = 4096 0:100 0:000 Type 17 Index = 1 0:100 0:000 SmbiosTable.Type17->Speed = 1600 0:100 0:000 SmbiosTable.Type17->Size = 4096 0:100 0:000 Type 17 Index = 2 0:100 0:000 SmbiosTable.Type17->Speed = 1600 0:100 0:000 SmbiosTable.Type17->Size = 4096 0:100 0:000 Type 17 Index = 3 0:100 0:000 SmbiosTable.Type17->Speed = 1600 0:100 0:000 SmbiosTable.Type17->Size = 4096 0:100 0:000 Boot status=0 0:100 0:000 Clover revision: 2652 running on Z87X-UD4H 0:100 0:000 ... with board Z87X-UD4H-CF 0:100 0:000 Clover load options size = 0 bytes 0:119 0:018 Using OEM config.plist at path: EFI\CLOVER\config.plist 0:119 0:000 EFI\CLOVER\config.plist loaded: Success 0:145 0:026 Found theme ICLOVER 0:147 0:002 Found theme applestyle 0:161 0:013 Found theme BGM 0:178 0:017 Found theme black_green 0:197 0:019 Found theme BLUEMAC 0:200 0:003 Found theme BOOTCAMP 0:205 0:004 Found theme magnifico 0:209 0:004 Found theme METAL 0:217 0:007 Found theme MRENGLES 0:219 0:002 Found theme ORANGE 0:222 0:002 Found theme OS_BOX 0:226 0:004 Found theme OS_ONE 0:229 0:003 Found theme Shield 0:259 0:029 Found theme THINKPAD 0:262 0:003 Loading early settings 0:262 0:000 timeout set to 25 0:262 0:000 Default theme: iclover 0:262 0:000 LoadDrivers() start 0:275 0:012 Loading CsmVideoDxe-64.efi 0:276 0:001 - driver needs connecting 0:276 0:000 Loading DataHubDxe-64.efi 0:294 0:017 Loading EmuVariableUefi-64.efi 0:295 0:001 EmuVariableUefi Initialize: VariableCommonInitialize = Success, orig services stored, install gEmuVariableControlProtocolGuid = Success 0:296 0:000 Loading FSInject-64.efi 0:298 0:001 Loading OsxAptioFixDrv-64.efi 0:299 0:001 Loading OsxFatBinaryDrv-64.efi 0:301 0:001 Loading PartitionDxe-64.efi 0:302 0:001 - driver needs connecting 0:302 0:000 Loading VBoxHfs-64.efi 0:303 0:001 - driver needs connecting 0:303 0:000 3 drivers needs connecting ... 0:303 0:000 PlatformDriverOverrideProtocol->GetDriver overriden 0:303 0:000 Partition driver loaded: CD disconnect SuccessCD disconnect Success 0:303 0:000 Video driver loaded: disconnect Success 0:417 0:114 Searching for invalid DiskIo BY_DRIVER connects: not found, all ok 0:432 0:014 CsmVideoDriverBindingStart 0:432 0:000 mixed support=40010 0:432 0:000 Controller is [030000] 0:432 0:000 Check for VBE 0:450 0:018 found Detail Timing 1920x1080 0:450 0:000 found Detail Timing 1680x1050 0:525 0:075 0 1280x1024 attr=9B - ok, edid+, working, highest, pref=0 0:540 0:015 1 1024x768 attr=9B - ok, edid+, 1024x768, working 0:545 0:005 2 640x480 attr=9B - ok, edid+, 640x480, working 0:555 0:010 3 800x600 attr=9B - ok, edid+, 800x600, working 0:600 0:045 4 1920x1080 attr=9B - ok, edid+, working, highest, pref=4 0:600 0:000 CsmVideo: New mode: 4 1920x1080 - set 0:785 0:185 - SetMode pref 4 (4) = Success 0:785 0:000 CsmVideoCheckForVbe - Success 0:785 0:000 CsmVideoDriverBindingStart end Success 0:785 0:000 CsmVideo: New mode: 1 1024x768 - blocking that switch 0:785 0:000 CsmVideo: New mode: 1 1024x768 - blocking that switch 0:786 0:000 CsmVideo: New mode: 1 1024x768 - blocking that switch 1:223 0:437 LoadDrivers() end 1:223 0:000 EmuVariable InstallEmulation: orig vars copied, emu.var.services installed, CreateEvent VirtualAddressChange = Success, CreateEvent ExitBootServices = Success, done 1:231 0:008 SetScreenResolution: 1920x1080 - already set 1:231 0:000 Console modes reported: 4, available modes: 1:231 0:000 Mode 1: 80x25 (current mode) 1:231 0:000 Mode 2: 80x50 1:231 0:000 Mode 3: 100x31 1:231 0:000 Mode 4: 128x30 1:231 0:000 reinit: self device path=PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(1,GPT,C6303D1D-224C-47D4-9C4C-AE489C0AE0D1,0x28,0x64000) 1:231 0:000 new SelfHandle=6FE6FF98 1:231 0:000 CPU Vendor = 756E6547 Model=306C3 1:231 0:000 The CPU supported turbo 1:231 0:000 BrandString = Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz 1:231 0:000 MSR 0xE2 before patch 18000402 1:231 0:000 MSR 0xE4 00001814 1:231 0:000 MSR 0xCE F3012300 1:231 0:000 non-usable FLEX_RATIO = F0000 1:231 0:000 corrected FLEX_RATIO = E0000 1:231 0:000 FSBFrequency=105MHz 1:231 0:000 Corrected FSBFrequency=100MHz 1:231 0:000 Vendor/Model/Stepping: 0x756E6547/0x3C/0x3 1:231 0:000 Family/ExtFamily: 0x6/0x0 1:231 0:000 MaxDiv/MinDiv: 35.0/8 1:231 0:000 Turbo: 37/38/39/39 1:231 0:000 Features: 0xBFEBFBFF 1:231 0:000 Threads: 8 1:231 0:000 Cores: 4 1:231 0:000 FSB: 100 MHz 1:231 0:000 CPU: 3700 MHz 1:231 0:000 TSC: 3700 MHz 1:231 0:000 PIS: 400 MHz 1:231 0:000 PCI (00|00:00.00) : 8086 0C00 class=060000 1:231 0:000 PCI (00|00:02.00) : 8086 0412 class=030000 1:231 0:000 Found GFX model=Intel HD Graphics 4600 1:231 0:000 PCI (00|00:03.00) : 8086 0C0C class=040300 1:231 0:000 PCI (00|00:14.00) : 8086 8C31 class=0C0330 1:231 0:000 PCI (00|00:16.00) : 8086 8C3A class=078000 1:231 0:000 PCI (00|00:16.01) : FFFF FFFF class=FFFFFF 1:231 0:000 PCI (00|00:19.00) : 8086 153B class=020000 1:231 0:000 PCI (00|00:1A.00) : 8086 8C2D class=0C0320 1:231 0:000 PCI (00|00:1B.00) : 8086 8C20 class=040300 1:231 0:000 PCI (00|00:1C.00) : 8086 8C10 class=060400 1:231 0:000 PCI (00|00:1C.03) : 8086 8C16 class=060400 1:231 0:000 PCI (00|02:00.00) : 1C00 3250 class=070005 1:231 0:000 PCI (00|00:1C.04) : 8086 244E class=060401 1:231 0:000 PCI (00|03:00.00) : 8086 244E class=060401 1:231 0:000 PCI (00|04:00.00) : 1822 4E35 class=048000 1:231 0:000 PCI (00|00:1C.05) : 8086 8C1A class=060400 1:231 0:000 PCI (00|05:00.00) : 1B4B 9172 class=010601 1:231 0:000 PCI (00|00:1C.06) : 8086 8C1C class=060400 1:231 0:000 PCI (00|06:00.00) : 10EC 8176 class=028000 1:231 0:000 PCI (00|00:1D.00) : 8086 8C26 class=0C0320 1:231 0:000 PCI (00|00:1F.00) : 8086 8C44 class=060100 1:231 0:000 PCI (00|00:1F.02) : 8086 8C02 class=010601 1:231 0:000 PCI (00|00:1F.03) : 8086 8C22 class=0C0500 1:231 0:000 PCI (00|00:1F.06) : FFFF FFFF class=FFFFFF 1:231 0:000 ScanSPD() start 1:232 0:000 SMBus CmdReg: 0x1 1:232 0:000 Scanning SMBus [8086:8C22], mmio: 0xF0839004, ioport: 0xF040, hostc: 0x1 1:246 0:014 SPD[0]: Type 11 @0x50 1:254 0:008 DDR speed 1600MHz 1:254 0:000 Slot: 0 Type 24 4096MB 1600MHz Vendor=Kingston PartNo=KHX1600C10D38G SerialNo=070403020F0F080B 1:268 0:014 SPD[1]: Type 11 @0x51 1:277 0:008 DDR speed 1600MHz 1:277 0:000 Slot: 1 Type 24 4096MB 1600MHz Vendor=Kingston PartNo=KHX1600C10D38G SerialNo=060603060D070B0B 1:291 0:014 SPD[2]: Type 11 @0x52 1:300 0:008 DDR speed 1600MHz 1:300 0:000 Slot: 2 Type 24 4096MB 1600MHz Vendor=Kingston PartNo=KHX1600C10D38G SerialNo=0704030206050B0B 1:314 0:014 SPD[3]: Type 11 @0x53 1:322 0:008 DDR speed 1600MHz 1:322 0:000 Slot: 3 Type 24 4096MB 1600MHz Vendor=Kingston PartNo=KHX1600C10D38G SerialNo=070803020D0F0D02 1:450 0:127 ScanSPD() end 1:450 0:000 Get Acpi Tables List from RSDT: 1:450 0:000 Found table: FACP A M I len=132 1:450 0:000 Found table: APIC A M I len=146 1:450 0:000 Found table: FPDT A M I len=68 1:450 0:000 Found table: SSDT Cpu0Ist len=1337 1:450 0:000 Found table: SSDT CpuPm len=2776 1:450 0:000 Found table: MCFG len=60 1:450 0:000 Found table: HPET A M I len=56 1:450 0:000 Found table: SSDT SataTabl len=877 1:450 0:000 Found table: SSDT SaSsdt len=12953 1:450 0:000 Found table: BGRT A M I len=56 1:450 0:000 Found table: DMAR HSW len=144 1:450 0:000 Found table: MATS A M I len=52 1:450 0:000 Calibrated TSC frequency =3491919770 =3491MHz 1:450 0:000 Loading main settings 1:450 0:000 USB FixOwnership: true 1:450 0:000 Dropping 3 tables 1:450 0:000 Drop table 0 signature="DMAR" (52414D44) 1:450 0:000 set table: 52414D44, 0 to drop: true 1:450 0:000 1:450 0:000 Drop table 1 signature="SSDT" (54445353) table-id="CpuPm" (0000006D50757043) 1:450 0:000 set table: 54445353, 6D50757043 to drop: true 1:450 0:000 1:450 0:000 Drop table 2 signature="SSDT" (54445353) table-id="Cpu0Ist" (0074734930757043) 1:450 0:000 set table: 54445353, 74734930757043 to drop: true 1:450 0:000 1:450 0:000 Config set EnableC6: + 1:450 0:000 Config set MinMultiplier=8 1:450 0:000 Config set MaxMultiplier=35 1:450 0:000 Config set ChassisType=0xD 1:450 0:000 Config set CpuFreq=3500MHz 1:450 0:000 Config set BusSpeed=100000kHz 1:450 0:000 KextsToPatch: 1 requested 1:450 0:000 KextToPatch 0: AppleAHCIPort (External icons patch) Kext bin patch, data len: 8 1:450 0:000 Oem smbios.plist not found at path: EFI\CLOVER\smbios.plist 1:450 0:000 smbios.plist not found, not overriding config.plist 1:450 0:000 found 22 volumes with blockIO 1:450 0:000 0. Volume: 1:450 0:000 PciRoot(0x0)\Pci(0x1A,0x0)\USB(0x1,0x0)\USB(0x1,0x0) 1:450 0:000 USB volume 1:450 0:000 USB volume 1:450 0:000 Volume 'Whole Disc Boot', LegacyOS '', LegacyIcon(s) 'legacy', GUID = <null guid> 1:450 0:000 1. Volume: 1:450 0:000 PciRoot(0x0)\Pci(0x1A,0x0)\USB(0x1,0x0)\USB(0x1,0x0)\Scsi(0x0,0x1) 1:450 0:000 USB volume 1:450 0:000 USB volume 1:450 0:000 Volume 'Whole Disc Boot', LegacyOS '', LegacyIcon(s) 'legacy', GUID = <null guid> 1:450 0:000 2. Volume: 1:450 0:000 PciRoot(0x0)\Pci(0x1C,0x5)\Pci(0x0,0x0)\Ata(0x0) 1:450 0:000 Volume 'Whole Disc Boot', LegacyOS '', LegacyIcon(s) 'legacy', GUID = <null guid> 1:450 0:000 3. Volume: 1:450 0:000 PciRoot(0x0)\Pci(0x1C,0x5)\Pci(0x0,0x0)\Ata(0x0)\HD(1,GPT,1FF9856D-5BBC-4958-9269-FBAD371C6AC7,0x40800,0x15D4C9800) 1:450 0:000 Result of bootcode detection: bootable <null string> (<null string>) 1:450 0:000 Volume 'Legacy HD1', LegacyOS '', LegacyIcon(s) 'legacy', GUID = 1FF9856D-5BBC-4958-9269-FBAD371C6AC7 1:450 0:000 4. Volume: 1:450 0:000 PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x0,0xFFFF,0x0) 1:450 0:000 found optical drive 1:450 0:000 Volume 'Whole Disc Boot', LegacyOS '', LegacyIcon(s) 'legacy', GUID = <null guid> 1:450 0:000 5. Volume: 1:450 0:000 PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x1,0xFFFF,0x0) 1:450 0:000 found optical drive 1:450 0:000 Volume 'Whole Disc Boot', LegacyOS '', LegacyIcon(s) 'legacy', GUID = <null guid> 1:450 0:000 6. Volume: 1:450 0:000 PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x2,0xFFFF,0x0) 1:451 0:000 Volume 'Whole Disc Boot', LegacyOS '', LegacyIcon(s) 'legacy', GUID = <null guid> 1:451 0:000 7. Volume: 1:451 0:000 PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x3,0xFFFF,0x0) 1:451 0:000 Volume 'Whole Disc Boot', LegacyOS '', LegacyIcon(s) 'legacy', GUID = <null guid> 1:451 0:000 8. Volume: 1:451 0:000 PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0) 1:452 0:000 Volume 'Whole Disc Boot', LegacyOS '', LegacyIcon(s) 'legacy', GUID = <null guid> 1:452 0:000 9. Volume: 1:452 0:000 PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x5,0xFFFF,0x0) 1:452 0:000 Volume 'Whole Disc Boot', LegacyOS '', LegacyIcon(s) 'legacy', GUID = <null guid> 1:452 0:000 10. Volume: 1:452 0:000 PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x2,0xFFFF,0x0)\HD(1,GPT,0BEDA24E-C813-4381-B288-1EBEF401F00E,0x800,0x32000) 1:453 0:000 Result of bootcode detection: bootable Windows (vista,win) 1:478 0:024 Volume 'EFI', LegacyOS 'Windows', LegacyIcon(s) 'vista,win', GUID = 0BEDA24E-C813-4381-B288-1EBEF401F00E 1:478 0:000 11. Volume: 1:478 0:000 PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x2,0xFFFF,0x0)\HD(2,GPT,77ABA40D-65A1-487F-A29D-00F2CC880329,0x32800,0x40000) 1:478 0:000 Volume 'Legacy HD2', LegacyOS '', LegacyIcon(s) 'legacy', GUID = 77ABA40D-65A1-487F-A29D-00F2CC880329 1:478 0:000 12. Volume: 1:478 0:000 PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x2,0xFFFF,0x0)\HD(3,GPT,4F5831DB-11B5-4796-B9B9-F6CB76847F2C,0x72800,0xE8D91000) 1:479 0:000 Result of bootcode detection: bootable <null string> (<null string>) 1:479 0:000 Volume 'Legacy HD3', LegacyOS '', LegacyIcon(s) 'legacy', GUID = 4F5831DB-11B5-4796-B9B9-F6CB76847F2C 1:479 0:000 13. Volume: 1:479 0:000 PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x3,0xFFFF,0x0)\HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800) 1:480 0:000 Result of bootcode detection: bootable <null string> (<null string>) 1:489 0:009 Volume 'EFI', LegacyOS '', LegacyIcon(s) '<null string>', GUID = 834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB 1:489 0:000 14. Volume: 1:489 0:000 PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x3,0xFFFF,0x0)\HD(2,GPT,D0EF56AA-5521-4132-B7E7-BC45ECBD5A6E,0xF4000,0x7382B000) 1:490 0:000 Volume 'Legacy HD2', LegacyOS '', LegacyIcon(s) 'legacy', GUID = D0EF56AA-5521-4132-B7E7-BC45ECBD5A6E 1:490 0:000 15. Volume: 1:490 0:000 PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x3,0xFFFF,0x0)\HD(3,GPT,EA065082-AB6B-4DA0-8CCA-74EE422E3FA1,0x7391F000,0xDE7800) 1:490 0:000 Volume 'Legacy HD3', LegacyOS '', LegacyIcon(s) 'legacy', GUID = EA065082-AB6B-4DA0-8CCA-74EE422E3FA1 1:490 0:000 16. Volume: 1:490 0:000 PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(1,GPT,C6303D1D-224C-47D4-9C4C-AE489C0AE0D1,0x28,0x64000) 1:491 0:000 Result of bootcode detection: bootable <null string> (<null string>) 1:517 0:026 Volume 'EFI', LegacyOS '', LegacyIcon(s) '<null string>', GUID = C6303D1D-224C-47D4-9C4C-AE489C0AE0D1 1:517 0:000 This is SelfVolume !! 1:517 0:000 17. Volume: 1:517 0:000 PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(2,GPT,2B7274F0-6CD0-425E-9898-CA24235CE3FC,0x64028,0x3A2E1FE0) 1:518 0:000 Volume 'OS X Mavericks', LegacyOS '', LegacyIcon(s) '<null string>', GUID = 2B7274F0-6CD0-425E-9898-CA24235CE3FC 1:518 0:000 18. Volume: 1:518 0:000 PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x5,0xFFFF,0x0)\HD(1,GPT,060BBF79-4856-4E69-BC1B-12A16891A7C1,0x800,0x96000) 1:518 0:000 Result of bootcode detection: bootable Windows (vista,win) 1:518 0:000 Volume 'Legacy HD1', LegacyOS 'Windows', LegacyIcon(s) 'vista,win', GUID = 060BBF79-4856-4E69-BC1B-12A16891A7C1 1:518 0:000 19. Volume: 1:518 0:000 PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x5,0xFFFF,0x0)\HD(2,GPT,9B68F5E0-053A-4C66-9FB8-D4334C8664A0,0x96800,0x32000) 1:519 0:000 Result of bootcode detection: bootable Windows (vista,win) 1:551 0:031 Volume 'EFI', LegacyOS 'Windows', LegacyIcon(s) 'vista,win', GUID = 9B68F5E0-053A-4C66-9FB8-D4334C8664A0 1:551 0:000 20. Volume: 1:551 0:000 PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x5,0xFFFF,0x0)\HD(3,GPT,8140FA98-22FE-47C7-8BB3-571C2E81B02E,0xC8800,0x40000) 1:551 0:000 Volume 'Legacy HD3', LegacyOS '', LegacyIcon(s) 'legacy', GUID = 8140FA98-22FE-47C7-8BB3-571C2E81B02E 1:551 0:000 21. Volume: 1:551 0:000 PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x5,0xFFFF,0x0)\HD(4,GPT,988B9DA3-F877-4216-A61F-F0FA551D2C92,0x108800,0x745FE000) 1:552 0:000 Result of bootcode detection: bootable Windows (vista,win) 1:552 0:000 Volume 'Legacy HD4', LegacyOS 'Windows', LegacyIcon(s) 'vista,win', GUID = 988B9DA3-F877-4216-A61F-F0FA551D2C92 1:552 0:000 Searching volumes for latest nvram.plist ... 1:552 0:000 10. Volume 'EFI', GUID = 0BEDA24E-C813-4381-B288-1EBEF401F00E - no nvram.plist - skipping! 1:552 0:000 13. Volume 'EFI', GUID = 834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB - no nvram.plist - skipping! 1:552 0:000 16. Volume 'EFI', GUID = C6303D1D-224C-47D4-9C4C-AE489C0AE0D1 - no nvram.plist - skipping! 1:552 0:000 17. Volume 'OS X Mavericks', GUID = 2B7274F0-6CD0-425E-9898-CA24235CE3FC - no nvram.plist - skipping! 1:566 0:013 19. Volume 'EFI', GUID = 9B68F5E0-053A-4C66-9FB8-D4334C8664A0 - no nvram.plist - skipping! 1:566 0:000 nvram.plist not found! 1:566 0:000 PutNvramPlistToRtVars: nvram.plist not found 1:566 0:000 Invalidating BuiltinIcons... 1:580 0:014 Using theme 'iclover' (EFI\CLOVER\themes\iclover) 1:585 0:004 font WoB_Hellfire_Bold_9W.png loaded from themedir 1:585 0:000 Font loaded: ImageWidth=176 ImageHeight=288 1:585 0:000 Font 2 prepared WxH=11x18 CharWidth=10 1:585 0:000 Choosing theme iclover 1:585 0:000 Custom entries start 1:585 0:000 Custom entry 0 "\System\Library\CoreServices\boot.efi" "" (1) 0x0 matching "HD(2,GPT,2B7274F0-6CD0-425E-9898-CA24235CE3FC,0x64028,0x3A2E1FE0)" ... 1:585 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x2,0xFFFF,0x0)\HD(1,GPT,0BEDA24E-C813-4381-B288-1EBEF401F00E,0x800,0x32000)) ... skipped 1:585 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x3,0xFFFF,0x0)\HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)) ... skipped 1:585 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(1,GPT,C6303D1D-224C-47D4-9C4C-AE489C0AE0D1,0x28,0x64000)) ... skipped 1:585 0:000 Checking volume "OS X Mavericks" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(2,GPT,2B7274F0-6CD0-425E-9898-CA24235CE3FC,0x64028,0x3A2E1FE0)) ... match! 1:639 0:053 Check if volume Is Hibernated: 1:639 0:000 Check sleep image 'by signature': 1:683 0:043 read prefs \Library\Preferences\SystemConfiguration\com.apple.PowerManagement.plist status=Success 1:683 0:000 SleepImage name from pref: ImageVolume = 'OS X Mavericks', ImageName = '\private\var\vm\sleepimage' 1:695 0:012 Reading first 512 bytes of sleepimage ... 1:708 0:012 OurBlockIoRead: Lba=2224038, Offset=444807000 (BlockSize=512) 1:708 0:000 sig lion: 0 1:708 0:000 sig snow: 0 1:708 0:000 no valid sleep image offset was found 1:708 0:000 Reading completed -> Success 1:708 0:000 sleepimage offset could not be acquired 1:708 0:000 hibernated: no - sign 1:732 0:023 found PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(2,GPT,2B7274F0-6CD0-425E-9898-CA24235CE3FC,0x64028,0x3A2E1FE0)\System\Library\CoreServices\boot.efi 1:733 0:001 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x5,0xFFFF,0x0)\HD(2,GPT,9B68F5E0-053A-4C66-9FB8-D4334C8664A0,0x96800,0x32000)) ... skipped 1:733 0:000 Custom entry 1 "\EFI\Microsoft\Boot\bootmgfw.efi" "-s -h" (7) 0x0 matching "HD(1,GPT,0BEDA24E-C813-4381-B288-1EBEF401F00E,0x800,0x32000)" ... 1:733 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x2,0xFFFF,0x0)\HD(1,GPT,0BEDA24E-C813-4381-B288-1EBEF401F00E,0x800,0x32000)) ... match! 1:739 0:006 found PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x2,0xFFFF,0x0)\HD(1,GPT,0BEDA24E-C813-4381-B288-1EBEF401F00E,0x800,0x32000)\EFI\Microsoft\Boot\bootmgfw.efi 1:739 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x3,0xFFFF,0x0)\HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)) ... skipped 1:739 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(1,GPT,C6303D1D-224C-47D4-9C4C-AE489C0AE0D1,0x28,0x64000)) ... skipped 1:739 0:000 Checking volume "OS X Mavericks" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(2,GPT,2B7274F0-6CD0-425E-9898-CA24235CE3FC,0x64028,0x3A2E1FE0)) ... skipped 1:739 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x5,0xFFFF,0x0)\HD(2,GPT,9B68F5E0-053A-4C66-9FB8-D4334C8664A0,0x96800,0x32000)) ... skipped 1:739 0:000 Custom entry 2 "\EFI\Microsoft\Boot\bootmgfw.efi" "-s -h" (7) 0x0 matching "HD(2,GPT,9B68F5E0-053A-4C66-9FB8-D4334C8664A0,0x96800,0x32000)" ... 1:739 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x2,0xFFFF,0x0)\HD(1,GPT,0BEDA24E-C813-4381-B288-1EBEF401F00E,0x800,0x32000)) ... skipped 1:739 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x3,0xFFFF,0x0)\HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)) ... skipped 1:739 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(1,GPT,C6303D1D-224C-47D4-9C4C-AE489C0AE0D1,0x28,0x64000)) ... skipped 1:739 0:000 Checking volume "OS X Mavericks" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(2,GPT,2B7274F0-6CD0-425E-9898-CA24235CE3FC,0x64028,0x3A2E1FE0)) ... skipped 1:739 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x5,0xFFFF,0x0)\HD(2,GPT,9B68F5E0-053A-4C66-9FB8-D4334C8664A0,0x96800,0x32000)) ... match! 1:743 0:003 found PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x5,0xFFFF,0x0)\HD(2,GPT,9B68F5E0-053A-4C66-9FB8-D4334C8664A0,0x96800,0x32000)\EFI\Microsoft\Boot\bootmgfw.efi 1:743 0:000 Custom entry 3 "\EFI\grub\grubx64.efi" "" (4) 0x0 matching "HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)" ... 1:743 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x2,0xFFFF,0x0)\HD(1,GPT,0BEDA24E-C813-4381-B288-1EBEF401F00E,0x800,0x32000)) ... skipped 1:743 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x3,0xFFFF,0x0)\HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)) ... skipped because path does not exist 1:743 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(1,GPT,C6303D1D-224C-47D4-9C4C-AE489C0AE0D1,0x28,0x64000)) ... skipped 1:743 0:000 Checking volume "OS X Mavericks" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(2,GPT,2B7274F0-6CD0-425E-9898-CA24235CE3FC,0x64028,0x3A2E1FE0)) ... skipped 1:743 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x5,0xFFFF,0x0)\HD(2,GPT,9B68F5E0-053A-4C66-9FB8-D4334C8664A0,0x96800,0x32000)) ... skipped 1:743 0:000 Custom entry 3 "\EFI\Gentoo\grubx64.efi" "" (4) 0x0 matching "HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)" ... 1:743 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x2,0xFFFF,0x0)\HD(1,GPT,0BEDA24E-C813-4381-B288-1EBEF401F00E,0x800,0x32000)) ... skipped 1:743 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x3,0xFFFF,0x0)\HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)) ... skipped because path does not exist 1:743 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(1,GPT,C6303D1D-224C-47D4-9C4C-AE489C0AE0D1,0x28,0x64000)) ... skipped 1:743 0:000 Checking volume "OS X Mavericks" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(2,GPT,2B7274F0-6CD0-425E-9898-CA24235CE3FC,0x64028,0x3A2E1FE0)) ... skipped 1:743 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x5,0xFFFF,0x0)\HD(2,GPT,9B68F5E0-053A-4C66-9FB8-D4334C8664A0,0x96800,0x32000)) ... skipped 1:743 0:000 Custom entry 3 "\EFI\Gentoo\kernelx64.efi" "" (4) 0x0 matching "HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)" ... 1:743 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x2,0xFFFF,0x0)\HD(1,GPT,0BEDA24E-C813-4381-B288-1EBEF401F00E,0x800,0x32000)) ... skipped 1:743 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x3,0xFFFF,0x0)\HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)) ... skipped because path does not exist 1:743 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(1,GPT,C6303D1D-224C-47D4-9C4C-AE489C0AE0D1,0x28,0x64000)) ... skipped 1:743 0:000 Checking volume "OS X Mavericks" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(2,GPT,2B7274F0-6CD0-425E-9898-CA24235CE3FC,0x64028,0x3A2E1FE0)) ... skipped 1:743 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x5,0xFFFF,0x0)\HD(2,GPT,9B68F5E0-053A-4C66-9FB8-D4334C8664A0,0x96800,0x32000)) ... skipped 1:743 0:000 Custom entry 3 "\EFI\RedHat\grubx64.efi" "" (4) 0x0 matching "HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)" ... 1:743 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x2,0xFFFF,0x0)\HD(1,GPT,0BEDA24E-C813-4381-B288-1EBEF401F00E,0x800,0x32000)) ... skipped 1:743 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x3,0xFFFF,0x0)\HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)) ... skipped because path does not exist 1:743 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(1,GPT,C6303D1D-224C-47D4-9C4C-AE489C0AE0D1,0x28,0x64000)) ... skipped 1:743 0:000 Checking volume "OS X Mavericks" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(2,GPT,2B7274F0-6CD0-425E-9898-CA24235CE3FC,0x64028,0x3A2E1FE0)) ... skipped 1:743 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x5,0xFFFF,0x0)\HD(2,GPT,9B68F5E0-053A-4C66-9FB8-D4334C8664A0,0x96800,0x32000)) ... skipped 1:743 0:000 Custom entry 3 "\EFI\ubuntu\grubx64.efi" "" (4) 0x0 matching "HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)" ... 1:743 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x2,0xFFFF,0x0)\HD(1,GPT,0BEDA24E-C813-4381-B288-1EBEF401F00E,0x800,0x32000)) ... skipped 1:743 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x3,0xFFFF,0x0)\HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)) ... match! 1:757 0:014 found PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x3,0xFFFF,0x0)\HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)\EFI\ubuntu\grubx64.efi 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(1,GPT,C6303D1D-224C-47D4-9C4C-AE489C0AE0D1,0x28,0x64000)) ... skipped 1:757 0:000 Checking volume "OS X Mavericks" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(2,GPT,2B7274F0-6CD0-425E-9898-CA24235CE3FC,0x64028,0x3A2E1FE0)) ... skipped 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x5,0xFFFF,0x0)\HD(2,GPT,9B68F5E0-053A-4C66-9FB8-D4334C8664A0,0x96800,0x32000)) ... skipped 1:757 0:000 Custom entry 3 "\EFI\kubuntu\grubx64.efi" "" (4) 0x0 matching "HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)" ... 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x2,0xFFFF,0x0)\HD(1,GPT,0BEDA24E-C813-4381-B288-1EBEF401F00E,0x800,0x32000)) ... skipped 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x3,0xFFFF,0x0)\HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)) ... skipped because path does not exist 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(1,GPT,C6303D1D-224C-47D4-9C4C-AE489C0AE0D1,0x28,0x64000)) ... skipped 1:757 0:000 Checking volume "OS X Mavericks" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(2,GPT,2B7274F0-6CD0-425E-9898-CA24235CE3FC,0x64028,0x3A2E1FE0)) ... skipped 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x5,0xFFFF,0x0)\HD(2,GPT,9B68F5E0-053A-4C66-9FB8-D4334C8664A0,0x96800,0x32000)) ... skipped 1:757 0:000 Custom entry 3 "\EFI\LinuxMint\grubx64.efi" "" (4) 0x0 matching "HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)" ... 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x2,0xFFFF,0x0)\HD(1,GPT,0BEDA24E-C813-4381-B288-1EBEF401F00E,0x800,0x32000)) ... skipped 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x3,0xFFFF,0x0)\HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)) ... skipped because path does not exist 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(1,GPT,C6303D1D-224C-47D4-9C4C-AE489C0AE0D1,0x28,0x64000)) ... skipped 1:757 0:000 Checking volume "OS X Mavericks" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(2,GPT,2B7274F0-6CD0-425E-9898-CA24235CE3FC,0x64028,0x3A2E1FE0)) ... skipped 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x5,0xFFFF,0x0)\HD(2,GPT,9B68F5E0-053A-4C66-9FB8-D4334C8664A0,0x96800,0x32000)) ... skipped 1:757 0:000 Custom entry 3 "\EFI\Fedora\grubx64.efi" "" (4) 0x0 matching "HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)" ... 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x2,0xFFFF,0x0)\HD(1,GPT,0BEDA24E-C813-4381-B288-1EBEF401F00E,0x800,0x32000)) ... skipped 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x3,0xFFFF,0x0)\HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)) ... skipped because path does not exist 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(1,GPT,C6303D1D-224C-47D4-9C4C-AE489C0AE0D1,0x28,0x64000)) ... skipped 1:757 0:000 Checking volume "OS X Mavericks" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(2,GPT,2B7274F0-6CD0-425E-9898-CA24235CE3FC,0x64028,0x3A2E1FE0)) ... skipped 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x5,0xFFFF,0x0)\HD(2,GPT,9B68F5E0-053A-4C66-9FB8-D4334C8664A0,0x96800,0x32000)) ... skipped 1:757 0:000 Custom entry 3 "\EFI\opensuse\grubx64.efi" "" (4) 0x0 matching "HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)" ... 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x2,0xFFFF,0x0)\HD(1,GPT,0BEDA24E-C813-4381-B288-1EBEF401F00E,0x800,0x32000)) ... skipped 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x3,0xFFFF,0x0)\HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)) ... skipped because path does not exist 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(1,GPT,C6303D1D-224C-47D4-9C4C-AE489C0AE0D1,0x28,0x64000)) ... skipped 1:757 0:000 Checking volume "OS X Mavericks" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(2,GPT,2B7274F0-6CD0-425E-9898-CA24235CE3FC,0x64028,0x3A2E1FE0)) ... skipped 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x5,0xFFFF,0x0)\HD(2,GPT,9B68F5E0-053A-4C66-9FB8-D4334C8664A0,0x96800,0x32000)) ... skipped 1:757 0:000 Custom entry 3 "\EFI\arch\grubx64.efi" "" (4) 0x0 matching "HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)" ... 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x2,0xFFFF,0x0)\HD(1,GPT,0BEDA24E-C813-4381-B288-1EBEF401F00E,0x800,0x32000)) ... skipped 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x3,0xFFFF,0x0)\HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)) ... skipped because path does not exist 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(1,GPT,C6303D1D-224C-47D4-9C4C-AE489C0AE0D1,0x28,0x64000)) ... skipped 1:757 0:000 Checking volume "OS X Mavericks" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(2,GPT,2B7274F0-6CD0-425E-9898-CA24235CE3FC,0x64028,0x3A2E1FE0)) ... skipped 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x5,0xFFFF,0x0)\HD(2,GPT,9B68F5E0-053A-4C66-9FB8-D4334C8664A0,0x96800,0x32000)) ... skipped 1:757 0:000 Custom entry 3 "\EFI\arch_grub\grubx64.efi" "" (4) 0x0 matching "HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)" ... 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x2,0xFFFF,0x0)\HD(1,GPT,0BEDA24E-C813-4381-B288-1EBEF401F00E,0x800,0x32000)) ... skipped 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x3,0xFFFF,0x0)\HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)) ... skipped because path does not exist 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(1,GPT,C6303D1D-224C-47D4-9C4C-AE489C0AE0D1,0x28,0x64000)) ... skipped 1:757 0:000 Checking volume "OS X Mavericks" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(2,GPT,2B7274F0-6CD0-425E-9898-CA24235CE3FC,0x64028,0x3A2E1FE0)) ... skipped 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x5,0xFFFF,0x0)\HD(2,GPT,9B68F5E0-053A-4C66-9FB8-D4334C8664A0,0x96800,0x32000)) ... skipped 1:757 0:000 Custom entry 3 "\EFI\SuSe\elilo.efi" "" (4) 0x0 matching "HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)" ... 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x2,0xFFFF,0x0)\HD(1,GPT,0BEDA24E-C813-4381-B288-1EBEF401F00E,0x800,0x32000)) ... skipped 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x3,0xFFFF,0x0)\HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)) ... skipped because path does not exist 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(1,GPT,C6303D1D-224C-47D4-9C4C-AE489C0AE0D1,0x28,0x64000)) ... skipped 1:757 0:000 Checking volume "OS X Mavericks" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(2,GPT,2B7274F0-6CD0-425E-9898-CA24235CE3FC,0x64028,0x3A2E1FE0)) ... skipped 1:757 0:000 Checking volume "EFI" (PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x5,0xFFFF,0x0)\HD(2,GPT,9B68F5E0-053A-4C66-9FB8-D4334C8664A0,0x96800,0x32000)) ... skipped 1:757 0:000 Custom entry 4 skipped because it is hidden. 1:757 0:000 Custom entries finish 1:757 0:000 Scanning loaders... 1:757 0:000 0: 'Whole Disc Boot' no file system 1:757 0:000 1: 'Whole Disc Boot' no file system 1:757 0:000 2: 'Whole Disc Boot' no file system 1:757 0:000 3: 'Legacy HD1' no file system 1:757 0:000 4: 'Whole Disc Boot' no file system 1:757 0:000 5: 'Whole Disc Boot' no file system 1:757 0:000 6: 'Whole Disc Boot' no file system 1:757 0:000 7: 'Whole Disc Boot' no file system 1:757 0:000 8: 'Whole Disc Boot' no file system 1:757 0:000 9: 'Whole Disc Boot' no file system 1:757 0:000 10: 'EFI' 1:757 0:000 skipped because path `PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x2,0xFFFF,0x0)\HD(1,GPT,0BEDA24E-C813-4381-B288-1EBEF401F00E,0x800,0x32000)\EFI\Microsoft\Boot\bootmgfw.efi` already exists for another entry! 1:766 0:008 skipped path `PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x2,0xFFFF,0x0)\HD(1,GPT,0BEDA24E-C813-4381-B288-1EBEF401F00E,0x800,0x32000)\EFI\BOOT\BOOTX64.efi` because it is a volume, volumetype and type match for custom entry 4! 1:766 0:000 11: 'Legacy HD2' no file system 1:766 0:000 12: 'Legacy HD3' no file system 1:766 0:000 13: 'EFI' 1:769 0:003 skipped because path `PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x3,0xFFFF,0x0)\HD(1,GPT,834F6EF8-CCAB-43EC-BAEE-13CD3DEA2FDB,0x800,0xF3800)\EFI\ubuntu\grubx64.efi` already exists for another entry! 1:773 0:004 14: 'Legacy HD2' no file system 1:773 0:000 15: 'Legacy HD3' no file system 1:773 0:000 16: 'EFI' 1:793 0:019 skipped because path `PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(1,GPT,C6303D1D-224C-47D4-9C4C-AE489C0AE0D1,0x28,0x64000)\EFI\BOOT\BOOTX64.efi` is self path! 1:793 0:000 17: 'OS X Mavericks' 1:793 0:000 skipped because path `PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(2,GPT,2B7274F0-6CD0-425E-9898-CA24235CE3FC,0x64028,0x3A2E1FE0)\System\Library\CoreServices\boot.efi` already exists for another entry! 1:802 0:008 18: 'Legacy HD1' no file system 1:802 0:000 19: 'EFI' 1:802 0:000 skipped because path `PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x5,0xFFFF,0x0)\HD(2,GPT,9B68F5E0-053A-4C66-9FB8-D4334C8664A0,0x96800,0x32000)\EFI\Microsoft\Boot\bootmgfw.efi` already exists for another entry! 1:810 0:008 skipped path `PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x5,0xFFFF,0x0)\HD(2,GPT,9B68F5E0-053A-4C66-9FB8-D4334C8664A0,0x96800,0x32000)\EFI\BOOT\BOOTX64.efi` because it is a volume, volumetype and type match for custom entry 4! 1:810 0:000 20: 'Legacy HD3' no file system 1:810 0:000 21: 'Legacy HD4' no file system 1:810 0:000 Custom legacy start 1:810 0:000 Custom legacy end 1:810 0:000 Custom tool start 1:810 0:000 Custom tool end 1:830 0:019 EmuVariable InstallEmulation: EFI_ALREADY_STARTED 1:830 0:000 GetEfiBootDeviceFromNvram: efi-boot-device-data not found 1:830 0:000 EfiBootVolume not found 1:830 0:000 Searching for DefaultVolume 'OS X Mavericks' ... 1:830 0:000 found entry 0. 'OS X Mavericks', Volume 'OS X Mavericks', DevicePath 'PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x4,0xFFFF,0x0)\HD(2,GPT,2B7274F0-6CD0-425E-9898-CA24235CE3FC,0x64028,0x3A2E1FE0)\System\Library\CoreServices\boot.efi' 1:830 0:000 EmuVariable UninstallEmulation: CloseEvent = Success, original var services restored 1:830 0:000 DefaultIndex=0 and MainMenu.EntryCount=8 1:830 0:000 Use anime=iClover_logo frames=4 1:846 0:015 found 4 frames of the anime 2:035 0:188 Found Mouse device: 2:036 0:001 GUI ready 4:158 2:121 StartLoader() start 4:158 0:000 Finally: Bus=100000kHz CPU=3500MHz 4:158 0:000 Loading boot.efi 4:420 0:261 EmuVariable InstallEmulation: orig vars copied, emu.var.services installed, CreateEvent VirtualAddressChange = Success, CreateEvent ExitBootServices = Success, done 4:428 0:008 insert table 9 for Airport 4:429 0:000 Injecting user memory modules to SMBIOS 4:429 0:000 Channels: 2 4:429 0:000 Interleave: 0 2 1 3 4 6 5 7 8 10 9 11 12 14 13 15 16 18 17 19 20 22 21 23 4:429 0:000 BANK0 DIMM0 1600MHz 4096MB 4:429 0:000 mTotalSystemMemory = 4096 4:429 0:000 BANK1 DIMM0 1600MHz 4096MB 4:429 0:000 mTotalSystemMemory = 8192 4:429 0:000 BANK0 DIMM1 1600MHz 4096MB 4:429 0:000 mTotalSystemMemory = 12288 4:429 0:000 BANK1 DIMM1 1600MHz 4096MB 4:429 0:000 mTotalSystemMemory = 16384 4:429 0:000 NumberOfMemoryDevices = 4 4:429 0:000 Type20[0]->End = 0x3FFFFF, Type17[0] = 0x1000 4:429 0:000 Type20[1]->End = 0xBFFFFF, Type17[2] = 0x4000 4:429 0:000 Type20[2]->End = 0x7FFFFF, Type17[1] = 0x6000 4:429 0:000 Type20[3]->End = 0xFFFFFF, Type17[3] = 0xA000 4:429 0:000 Table 131 is present, CPUType=10 4:429 0:000 Change to: 705 4:429 0:000 RSDT 0x7E1C3028 4:429 0:000 FADT from RSDT: 0x7E1C3118 4:429 0:000 XSDT 0x7E1C3080 4:429 0:000 FADT from XSDT: 0x7E1CF090 4:429 0:000 Xsdt reallocation done 4:429 0:000 old FADT length=10C 4:429 0:000 Found OperationRegion(GNVS, SystemMemory, 7E1EAC18, ...) 4:429 0:000 Found OperationRegion(MCHT, SystemMemory, FED10000, ...) 4:429 0:000 Found OperationRegion(RCRB, SystemMemory, FED1C000, ...) 4:429 0:000 Found OperationRegion(CPSB, SystemMemory, 7E0FBE18, ...) 4:429 0:000 Found OperationRegion(MBAR, SystemMemory, 0, ...) 4:429 0:000 Found OperationRegion(TMMB, SystemMemory, FED40000, ...) 4:429 0:000 Found OperationRegion(GCAD, SystemMemory, 7E1DA018, ...) 4:429 0:000 Found OperationRegion(GDAD, SystemMemory, 7E1D8018, ...) 4:429 0:000 Found OperationRegion(PRFA, SystemMemory, 0, ...) 4:430 0:001 DSDT found in Clover volume OEM folder: EFI\CLOVER\ACPI\patched\DSDT.aml 4:439 0:009 page is allocated, write DSDT into 4:439 0:000 Apply DsdtFixMask=0x00000000 old way 4:439 0:000 drop _DSM mask=0x0000 4:439 0:000 ========= Auto patch DSDT Starting ======== 4:439 0:000 VideoCard devID=0x4128086 4:439 0:000 DisplayADR1[0] = 0x20000, DisplayADR2[0] = 0xFFFE 4:439 0:000 Display 0 is notPCIE 4:439 0:000 USBADR[0] = 0x140000 and PCIe = 0xFFFE 4:439 0:000 USBADR[1] = 0x1A0000 and PCIe = 0xFFFE 4:688 0:249 Audio HDA (addr:0x1B0000) setting specified layout-id=898 (0x382) 4:688 0:000 USBADR[2] = 0x1D0000 and PCIe = 0xFFFE 4:688 0:000 Found ACPI CPU: CPU0 And CPU1 And CPU2 And CPU3 And CPU4 And CPU5 And CPU6 And CPU7 4:689 0:000 Found PCIROOTUID = 0 4:689 0:000 ========= Auto patch DSDT Finished ======== 4:689 0:000 Attempting to drop "DMAR" (52414D44) " HSW " (0000000020575348) L=144 4:689 0:000 Drop tables from Xsdt, SIGN=DMAR TableID=HSW Length=144 4:689 0:000 Xsdt has tables count=12 4:689 0:000 Table: DMAR HSW 144 dropped 4:689 0:000 corrected XSDT length=124 4:689 0:000 Attempting to drop "SSDT" (54445353) " CpuPm" (0000006D50757043) L=2776 4:689 0:000 Drop tables from Xsdt, SIGN=SSDT TableID=CpuPm Length=2776 4:689 0:000 Xsdt has tables count=11 4:689 0:000 Table: SSDT CpuPm 2776 dropped 4:689 0:000 corrected XSDT length=116 4:689 0:000 Attempting to drop "SSDT" (54445353) " Cpu0Ist" (0074734930757043) L=1337 4:689 0:000 Drop tables from Xsdt, SIGN=SSDT TableID=Cpu0Ist Length=1337 4:689 0:000 Xsdt has tables count=10 4:689 0:000 Table: SSDT Cpu0Ist 1337 dropped 4:689 0:000 corrected XSDT length=108 4:689 0:000 Patch table: SSDT SataTabl 4:689 0:000 SSDT len = 0x36D 4:689 0:000 Patch table: SSDT SaSsdt 4:689 0:000 SSDT len = 0x3299 4:689 0:000 Drop tables from Xsdt, SIGN=XXXX TableID= Length=0 4:689 0:000 Xsdt has tables count=9 4:689 0:000 corrected XSDT length=108 4:689 0:000 CPUBase=0 and ApicCPUBase=1 ApicCPUNum=8 4:689 0:000 Using custom MaxMultiplier 35 instead of automatic 35 4:689 0:000 Maximum control=23 4:689 0:000 Turbo control=27 4:689 0:000 P-States: min 0x8, max 0x27 4:689 0:000 SSDT with CPU P-States generated successfully 4:689 0:000 SSDT with CPU C-States generated successfully 4:689 0:000 EdidDiscovered size=128 4:689 0:000 00 | 00 FF FF FF FF FF FF 00 1E 6D DC 58 01 01 01 01 4:689 0:000 16 | 01 16 01 03 80 35 1E 78 EA 27 55 A3 54 4F 9E 27 4:689 0:000 32 | 11 50 54 A5 6F 00 71 4F 81 C0 81 00 81 80 95 00 4:689 0:000 48 | 90 40 A9 C0 B3 00 02 3A 80 18 71 38 2D 40 58 2C 4:689 0:000 64 | 45 00 DC 0B 11 00 00 1A 21 39 90 30 62 1A 27 40 4:689 0:000 80 | 68 B0 36 00 DC 0B 11 00 00 1C 00 00 00 FD 00 38 4:689 0:000 96 | 4B 1E 53 0F 00 0A 20 20 20 20 20 20 00 00 00 FC 4:689 0:000 112 | 00 4D 32 32 35 32 44 0A 20 20 20 20 20 20 01 8E 4:689 0:000 Intel Intel HD Graphics 4600 [8086:0412] :: PciRoot(0x0)\Pci(0x2,0x0) 4:689 0:000 Intel GFX revision =0x6 4:689 0:000 HDA Controller [8086:0C0C] :: PciRoot(0x0)\Pci(0x3,0x0) => setting specified layout-id=898 (0x382) 4:689 0:000 USB Controller [8086:8C31] :: PciRoot(0x0)\Pci(0x14,0x0) 4:689 0:000 LAN Controller [8086:153B] :: PciRoot(0x0)\Pci(0x19,0x0) 4:689 0:000 USB Controller [8086:8C2D] :: PciRoot(0x0)\Pci(0x1A,0x0) 4:689 0:000 HDA Controller [8086:8C20] :: PciRoot(0x0)\Pci(0x1B,0x0) => setting specified layout-id=898 (0x382) 4:689 0:000 USB Controller [8086:8C26] :: PciRoot(0x0)\Pci(0x1D,0x0) 4:689 0:000 stringlength = 3298 4:690 0:000 CurrentMode: Width=1920 Height=1080 4:690 0:000 FSInjection: using kexts path: 'EFI\CLOVER\kexts\10.9' 4:693 0:003 Preparing kexts injection for arch=x86_64 from EFI\CLOVER\kexts\10.9 4:694 0:000 SetStartupDiskVolume: 4:694 0:000 * Volume: 'OS X Mavericks' 4:694 0:000 * LoaderPath: '<null string>' 4:694 0:000 * DevPath: OS X Mavericks 4:694 0:000 * GUID = 2B7274F0-6CD0-425E-9898-CA24235CE3FC 4:694 0:000 * efi-boot-device: <array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>2B7274F0-6CD0-425E-9898-CA24235CE3FC</string></dict></dict></dict></array> 4:694 0:000 Closing log    bien como vereis ahi hay mucha información tanto como datos para la sabios como información sobre los bancos de ram instalados, como frecuencia de cpu  etc......
     
    pero los que nos interesa ahora es como saber que  seleccionar los discos..... así que buscaremos entradas de disco que terminen en match o matching...
     en azul os marcare las entrada buenas de w7
    en  rojo las entradas buenas de w8 u 8.1
    en verde las de osx 
    en naranja las de linux 
     
    como veis ha sido facil encontrar las entradas ahora solo queda editarlas en el Clover según las imágenes que  yo de puesto y tildar las opciones que yo tengo tildadas
     
    custom (para poder personalizar las entradas y los iconos de las entradas) entries (para que detecte las entrdas) kernel ( esto solo lo usamos para que nos detecte el linux, ya que estos sistemas se detectan por Kernel.... ya que cuando actualizamos Linux , generalmente se actualiza el Kernel)   son casi todos los campos obligatorios excepto.....
     
    1. title/fulltitle que sirve para darle nombre al disco que veréis en al arranque  de Clover
    2.image  sirve para asignare una imagen en concreto a cada nombre (titule/fulltittle
    3. drive image esta es para asignarle la imagen al disco que os aparece ( pues hay discos sin lobo , otro con logo de windows , otro con logo Ubuntu y el que tiene el logo apple
     
    ya por ultimo solo nos queda crear una ultima entrada...
     en la cual pondremos en volume ----->EFI y de la cual solo tildaremos Hidden y SubEntrie (para que nos oculte las particiones EFI de todos los discos)
     
     Nota:
     
     1. este dump esta recién hecho y puesto que Clover ya tiene las entradas configuradas al hacer el dump sale como que alguna entrada ya existe, a    vosotros no os debería de salir eso....
     
     2. es dificil de saber cual es W7 y W8 pues en el dump no sale el nombre del S.O. solo que es vista y tal y puesto que tanto w7 Como W8 son vista  la Unica forma de saber cual es cual es probando y tomando nota de que uuid es de cada uno
     
     3. tb se puede dar el caso de que pongamos en uuid que nos sale como match , inicie el sistema operativo ,y todo funciones  bien , pero que nos saque el nombre(titule/full tittle) bien  en cuyo caso probaremos con otro uuid que este junto a este, aunque ponga skipped....
     
    subo unas imágenes de mi escritorio y de mi configuración del Clover........
     
      (este es mi escritorio)  esta es la vista de los discos duros que tiene el equipo , todos bien identificados .... excepto ubuntu , ya que ubuntu(Linux) aunque sea Unix igual que OS X ,  se necesita de un software para que OS X reconozca sistemas con particiones EXT3 u EXT4, que son el formato de los discos Linux.....  al igual que reconoce los discos NTFS(Windows pero no deja escribir en ellos..... si sacar datos de ellos pero no meter datos en ellos.... y es por el mismo motivo de antes .... que se necesita un software para poder escribir datos desde OS X a Windows( de HFS+ a NTFS)   al fin y al cabo esto solo sirve para meter y sacar datos de un sistema a otro..... con esos softs no ahorramos el trabajo de tener que copiar en un pen , reiniciar con el windows y volver a copiarlo   bueno aqui la configuracion del Clover.....   bueno y esos es todo no se si se me escapa algo... supongo que el amigo Maniac10 no tendrá problema en corregirme si se me escapa algo......   P.D Alos moderadores perdon por el trocho de ladrillo nuevamente..... lo siento pero es divicil explicar un tema tan extenso en pocas palabras...   Maniac10 he abierto un hilo nuevo sobre lo del audio hdmi alc898 grafica intel hd4600 en la seccion Maverikcs 10.9 , por si te quieres unir.....
  19. Like
    XAVIDENIA got a reaction from Maniac10 in Bienvenido CLOVER   
    Bueno, vamos por partes..........
     
     en mi caso tengo cada sistema operativo en un disco duro con su propio boot e instalado en gpt (uefi) ya que mi placa es híbrida quiero decir que tiene tanto la opción  de instalar sistemas optativos tanto en Uefi como en Legacy  y no se si lo que yo hice servirá para aquellos que tengan varios sistemas en un mismo disco duro..... para aquellos que tengan dudas pondré las respuesta al comando diskutil list........
     
    /dev/disk0
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        *2.0 TB     disk0
       1:                        EFI NO NAME                 104.9 MB   disk0s1
       2:         Microsoft Reserved                         134.2 MB   disk0s2
       3:       Microsoft Basic Data Windows 7               2.0 TB     disk0s3
    /dev/disk1
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        *1.0 TB     disk1
       1: DE94BBA4-06D1-4D40-A16A-BFD50179D6AC               314.6 MB   disk1s1
       2:                        EFI NO NAME                 104.9 MB   disk1s2
       3:         Microsoft Reserved                         134.2 MB   disk1s3
       4:       Microsoft Basic Data Windows 8.1             999.6 GB   disk1s4
    /dev/disk2
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        *1.0 TB     disk2
       1:                        EFI NO NAME                 510.7 MB   disk2s1
       2: 0FC63DAF-8483-4772-8E79-3D69D8477DE4               992.2 GB   disk2s2
       3:                 Linux Swap                         7.5 GB     disk2s3
    /dev/disk3
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        *500.1 GB   disk3
       1:                        EFI EFI                     209.7 MB   disk3s1
       2:                  Apple_HFS OS X Mavericks          499.8 GB   disk3s2
    /dev/disk4
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        *3.0 TB     disk4
       1:       Microsoft Basic Data Archivador              3.0 TB     disk4s1
    Mac-Pro-de-Xavidenia:~ xavidenia$ 
       como se ve aqui cada s.o instalado en uefi en su propio disco crea varias particiones en el caso de los windows crea las particiones de recuperación(Microsoft Reserved)
    y como no una partición Efi  donde esta el boot del windows al ser Efi, mac ya reconoce mas fácilmente esa partición pues es igual a la que el usa exceptuando los archivos internos que son el boot que windows crea al instalarlo en efi...........
    para instalar windows en uefi......
    1. windows 8 ya se instala generalmente en partición GPT y en uefi de no ser así  solo hay que crear un pendrive de arranque con W8 y cambiar en la bios a  boot only uefi y se instalara en uefi es necesario el pendrive pq es imposible arrancar en uefi desde cd, pues los lectores los reconoce como Legacy con lo cual al cambiar en la bios  a only UEFI ya no nos saldría la opción de arrancar desde Lector de Cd , Dvd , BlueRay pero si desde el usb y arrancaríamos desde una opción de dice UEFI + nombre del pendrive(UEFI Kingston data traveller, por ejemplo)
     
    2. en windows 7 hay es necesario crear un pendrive booteable de windows 7 uefi para eso nos podemos ayudar del software rufus 1.4.6.exe  
    es muy fácil de usar es como el unebootin pero para crear discos de instalación UEFI de windows y sirve para crear tanto w7 como W8 tarda un poco en crea el pen ....
    3. luego la instalación es igual como la de w8 (ojo los discos de so usados para crear el pen deben de ser simples, no disco como los que hay de windows 7 y 8 con todas sus versiónes de s.o también conocido como AiO y los s.o de 64 bits)
     
    4. para crear un linux uefi descargaremos una de las ultimas versiones en de linux según la distribución que estéis acostumbrados a usar  en 64 bits, y crearemos al igual que en windows un pendrive de arranque UEFI, para que tb se instale en uefi,
    esto lo haremos con otra herramienta muy fácil he intuitiva como es LinuxLive usb creador 2.8.27.exe que se ejecuta en windows..
     
    5. para la instalacion de los s.o recomiendo que en cada instalación solo este conectado el disco donde se va ha instalar dicho s.o,
    si no en cada instalación nos cargaremos el boot del otro sistema, por ejemplo si tenemos w7 instalado al instalar w8 o ubuntu nos jodería el boot de w7 y no queremos eso.....
        1.así que conectamos un disco instalamos w7
        2.desconectamos ese disco
        3.conectamos otro disco
        4. instalamos w8  
        5. desconectamos ese disco en el que acabamnos de instalar w8
        6.conectamos otro disco 
        7.instalamos Linux
        8.desconectamos disco donde acabamos de instalar linux
        9.conectamos otro disco 
      10.instalamos osx por ultimo
      12.instalamos kext de red( de lo contrario no podremos instalar el Clover configurator)
      13.configuramos osx e instalamos Clover y Clover configurator
      14.tras la instalacion de osx mientras lo configuramos recomiendo no conectar los demás discos.....asi nos evitaremos de crearles ningún daño
      15.para desconectar los disco solo es necesario apagar la pc y desconectar el cable sata, no es necesario desconectar la alimentación tb...
      16.solo conectaremos los demás discos cuando OS X arranque por si mismo con Clover  y este, esté bien configurado....
     
     (esta es la mejor forma de instalar pues si se nos jode Clover u OS X siempre podremos arrancar desde cualquier otro s.o simplemente eligiendo  el disco con el que quieres arrancar por medio de F12) 
     
    OS X  debe de ser la versión que queramos apartir de ML , pues Clover es incompatible con LION con lo cual la versión de os x a instalar debe de ser de ML para arriba
    ojo en la instalación de Clover  con el aparatado de instalar RC scripts ... ya que hay placas que dan problemas al instalar los Scripts RC y Clover no se ejecuta bien dando por resultado pantalla negra o blanca  y sin esos Scripts Clover funciona igual de bien que en placas que necesitan de dichos Scripts.......que fue mi caso......en caso que instalar los Scrits Rc y que  Clover no se visualice en el reinicio , recomiendo reinstalar de cero (en limpio de nuevo OS x ) y reinstalar Clover sin los Scripts esto, no nos llevara mas de media hora y vale la pena para no tener ningún archivo en doble que nos de problemas en el mac....... 
     
    17. vamos a pasar a configurar Clover con el Clover configurator.....  para ello necesitaremos el Darwin Dumper  en un post anterior de maniac10 me pone la pagina donde descargar la ultima versión de dicho programa que usaremos para sacar datos como frecuencia de la cpu latencia  y datos sobre nuestro hardware y funcionamiento de nuestro hardware que deberemos darle a Clover.......
    los datos los sacaremos de aplicaciones-->DarwinDumperReports---> dentro hay una carpeta ...... y dentro de esa carpeta otra llamada bootlog ----> y dentro de la carpeta bootlog varios archivos abrimos un txt llamado bootlog y ahí tendremos todos los datos para configurar Clover básicamente
    excepto la smbios que dedemos de buscar a que mac se parece nuestro hardware Mac Pro, imac , Mac mini...... en mi caso es un imac 14,2....
    una vez que sepamos a que mac se parece nuestro hardware iremos a la pestaña smBios y seleccionaremos dicha smBios y se nos llenaran casi todas las casillas con datos de seriales y cosas así....
     
    y hasta aqui lo dejo por ahora .......
    en el próximo post.....explicare como hacer para que Clover detecte todos los discos duros correctamente  con el nombre que nosotros queramos y con su propio disco de sistema , su propio icono junto al nombre y como personalizar dichos iconos....
     
    P.D.  A los moderadores.. Perdonad por el trocho ladrillo de post pero si no lo explico desde el principio hay muchas cositas que parecen tonterías y no lo son pues pueden dar problemas y romperte la cabeza y no dar con la solución como me pasaba a mi y al final di con la solución como por ejemplo lo de los rc Scripts que me tire 1 mes para dar con ello
  20. Like
    XAVIDENIA got a reaction from juanerson in Bienvenido CLOVER   
    Gracias por contestar tan pronto maniac10 ...... a ver si por fin consigo configurar el clover como yo quiero, si se puede, pq por mucho que  he buscado por internet y he probado configuraciones y posibles variaciones no lo he conseguido , quizás se me escapa algo .........
     
    aver este archivo es un dump extraídos con el darwin dumper........
     
    también te voy a subir el boot log extraído con el clver configurator.........
     
     
    y ahora dos config.plist con los que he estado trabajando la única diferencia entre uno y otro esta en que en uno solo tengo tildado en la pestaña fui la opción custom y destilad la opción entries con este no consigo que me salga la pantalla de carga de llover, o sea el tema iclover donde se seleccionan el disco con el que quieres arrancar, pero inicia directamente en mac, no sale la pantalla donde se introduce la contraseña, pero meto la contraseña e incia , aunque luego en el escritorio no tengo nada , ni el dock.....pienso que puede que tenga algún problema con algún driver....... 
    <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>SMBIOS</key> <dict> <key>BoardType</key> <integer>10</integer> <key>ChassisType</key> <integer>13</integer> <key>SmUUID</key> <string>9402de03-8004-a305-fd06-b20700080009</string> <key>BiosReleaseDate</key> <string>09/03/2013</string> <key>Version</key> <string>1.0</string> <key>SerialNumber</key> <string>C02KTIS1F8J3</string> <key>Manufacturer</key> <string>Apple Computer, Inc.</string> <key>BoardManufacturer</key> <string>Apple Computer, Inc.</string> <key>BoardSerialNumber</key> <string>C02140302D5DMT31M</string> <key>ChassisAssetTag</key> <string>iMac-Aluminum</string> <key>BiosVendor</key> <string>Apple Computer, Inc.</string> <key>ChassisManufacturer</key> <string>Apple Computer, Inc.</string> <key>BiosVersion</key> <string>IM141.88Z.0118.B00.1309031248</string> <key>Board-ID</key> <string>Mac-031B6874CF7F642A</string> <key>Family</key> <string>iMac</string> <key>ProductName</key> <string>iMac14,1</string> <key>LocationInChassis</key> <string>Part Component</string> <key>BoardVersion</key> <string>iMac14,1</string> <key>Trust</key> <true/> <key>Memory</key> <dict> <key>SlotCount</key> <integer>4</integer> <key>Channels</key> <integer>2</integer> <key>Modules</key> <array> <dict> <key>Slot</key> <integer>0</integer> <key>Size</key> <integer>4096</integer> <key>Frequency</key> <integer>1600</integer> <key>Vendor</key> <string>Kingston</string> <key>Part</key> <string>9905403-442.A00LF</string> <key>Serial</key> <string>0A02010C07080E0D</string> <key>Type</key> <string>DDR3</string> </dict> <dict> <key>Slot</key> <integer>2</integer> <key>Size</key> <integer>4096</integer> <key>Frequency</key> <integer>1600</integer> <key>Vendor</key> <string>Kingston</string> <key>Part</key> <string>9905403-442.A00LF</string> <key>Serial</key> <string>0A02010C0B070F0D</string> <key>Type</key> <string>DDR3</string> </dict> </array> </dict> </dict> <key>ACPI</key> <dict> <key>DSDT</key> <dict> <key>Debug</key> <false/> <key>ReuseFFFF</key> <false/> <key>Name</key> <string>DSDT.aml</string> <key>Fixes</key> <dict> <key>AddDTGP_0001</key> <false/> <key>AddMCHC_0008</key> <false/> <key>FakeLPC_0020</key> <false/> <key>FixAirport_4000</key> <false/> <key>FixDarwin_0002</key> <false/> <key>FixDisplay_0100</key> <false/> <key>FixFirewire_0800</key> <false/> <key>FixHDA_8000</key> <false/> <key>FixHPET_0010</key> <false/> <key>FixIDE_0200</key> <false/> <key>FixIPIC_0040</key> <false/> <key>FixLAN_2000</key> <false/> <key>FixSATA_0400</key> <false/> <key>FixSBUS_0080</key> <false/> <key>FixShutdown_0004</key> <false/> <key>FixUSB_1000</key> <false/> <key>NewWay_80000000</key> <true/> <key>FixRegions_10000000</key> <true/> <key>FIX_RTC_20000</key> <true/> <key>FiX_TMR_40000</key> <true/> <key>AddIMEI_80000</key> <true/> <key>FIX_INTELGFX_100000</key> <false/> <key>FiX_WAK_200000</key> <true/> <key>DeleteUnused_400000</key> <true/> <key>FIX_ADP1_800000</key> <true/> <key>AddPNLF_1000000</key> <true/> <key>FIX_S3D_2000000</key> <true/> <key>FIX_ACST_4000000</key> <true/> <key>AddHDMI_8000000</key> <true/> </dict> <key>DropOEM_DSM</key> <false/> </dict> <key>DropTables</key> <array> <dict> <key>Signature</key> <string>DMAR</string> </dict> <dict> <key>Signature</key> <string>SSDT</string> <key>TableId</key> <string>CpuPm</string> </dict> <dict> <key>Signature</key> <string>SSDT</string> <key>TableId</key> <string>Cpu0Ist</string> </dict> </array> <key>PatchAPIC</key> <true/> <key>SSDT</key> <dict> <key>DropOem</key> <false/> <key>UseSystemIO</key> <true/> <key>Generate</key> <dict> <key>PStates</key> <true/> <key>CStates</key> <true/> </dict> <key>MinMultiplier</key> <integer>8</integer> <key>MaxMultiplier</key> <integer>35</integer> <key>EnableC6</key> <true/> <key>C3Latency</key> <string>0X0</string> </dict> </dict> <key>Boot</key> <dict> <key>Arguments</key> <string>-v</string> <key>DefaultVolume</key> <string>OS X Mavericks</string> <key>Legacy</key> <string>PBR</string> <key>Log</key> <false/> <key>Timeout</key> <integer>20</integer> <key>XMPDetection</key> <string>No</string> <key>Secure</key> <false/> </dict> <key>Devices</key> <dict> <key>Audio</key> <dict> <key>Inject</key> <string>898</string> </dict> <key>FakeID</key> <dict> <key>ATI</key> <string>0x0</string> <key>IntelGFX</key> <string>0x0</string> <key>NVidia</key> <string>0x0</string> <key>LAN</key> <string>0x0</string> <key>SATA</key> <string>0x0</string> <key>WIFI</key> <string>0x0</string> <key>XHCI</key> <string>0x0</string> <key>IMEI</key> <string>0x0</string> </dict> <key>UseIntelHDMI</key> <true/> <key>USB</key> <dict> <key>Inject</key> <true/> <key>FixOwnership</key> <true/> <key>AddClockID</key> <true/> <key>HighCurrent</key> <true/> </dict> </dict> <key>GUI</key> <dict> <key>CustomIcons</key> <true/> <key>Language</key> <string>es:0</string> <key>ScreenResolution</key> <string>1920x1080</string> <key>Theme</key> <string>iclover</string> <key>Mouse</key> <dict> <key>DoubleClick</key> <integer>400</integer> <key>Speed</key> <integer>4</integer> <key>Enabled</key> <true/> </dict> <key>Scan</key> <false/> <key>Hide</key> <array> <string>\EFI\BOOT\BOOTX64.EFI</string> </array> <key>Custom</key> <dict> <key>Entries</key> <array> <dict> <key>Path</key> <string>\EFI\BOOT\BOOTX64.EFI</string> <key>FullTitle</key> <string>Internal EFI</string> <key>Hidden</key> <true/> <key>Disabled</key> <false/> <key>InjectKexts</key> <false/> <key>NoCaches</key> <false/> <key>Type</key> <string>OSX</string> <key>VolumeType</key> <string>Internal</string> </dict> <dict> <key>Volume</key> <string>DBAFC65B-EC1E-3852-9B49-C7C8FAEB0EB9</string> <key>AddArguments</key> <string>-v npci=2000</string> <key>FullTitle</key> <string>OS X Mavericks</string> <key>Image</key> <string>/EFI/CLOVER/themes/iclover/icons/os_mav.icns</string> <key>DriveImage</key> <string>/EFI/CLOVER/themes/iclover/icons/vol_internal_hfs.icns</string> <key>Hidden</key> <false/> <key>Disabled</key> <false/> <key>InjectKexts</key> <false/> <key>NoCaches</key> <false/> <key>Type</key> <string>OSX</string> <key>VolumeType</key> <string>Internal</string> </dict> <dict> <key>Volume</key> <string>6A9DF3AE-5ADD-4060-B61D-3ED156B69043</string> <key>Path</key> <string>\EFI\Microsoft\Boot\bootmgfw.efi</string> <key>FullTitle</key> <string>Windows 7</string> <key>Image</key> <string>/EFI/CLOVER/themes/iclover/icons/os_win.icns</string> <key>DriveImage</key> <string>/EFI/CLOVER/themes/iclover/icons/vol_internal_ntfs.icns</string> <key>Hidden</key> <false/> <key>Disabled</key> <false/> <key>Type</key> <string>Windows</string> <key>VolumeType</key> <string>Internal</string> </dict> <dict> <key>Volume</key> <string>822BAC0C-AA6E-49FB-9CCA-78AB650152AE</string> <key>Path</key> <string>\EFI\Microsoft\Boot\bootmgfw.efi</string> <key>FullTitle</key> <string>Windows 8.1</string> <key>Image</key> <string>/EFI/CLOVER/themes/iclover/icons/os_vista.icns</string> <key>DriveImage</key> <string>/EFI/CLOVER/themes/iclover/icons/vol_internal_ntfs.icns</string> <key>Hidden</key> <false/> <key>Disabled</key> <false/> <key>Type</key> <string>Windows</string> <key>VolumeType</key> <string>Internal</string> </dict> <dict> <key>Volume</key> <string>0FC63DAF-8483-4772-8E79-3D69D8477DE4 </string> <key>Path</key> <string>\EFI\ubuntu\grubx64.efi</string> <key>FullTitle</key> <string>Ubuntu 13.10</string> <key>Image</key> <string>/EFI/CLOVER/themes/iclover/icons/os_linux.icns</string> <key>DriveImage</key> <string>/EFI/CLOVER/themes/iclover/icons/vol_internal_ext3.icns</string> <key>Hidden</key> <false/> <key>Disabled</key> <false/> <key>Type</key> <string>LinuxKernel</string> <key>Kernel</key> <string>All</string> <key>VolumeType</key> <string>Internal</string> </dict> </array> </dict> </dict> <key>Graphics</key> <dict> <key>InjectEDID</key> <true/> <key>PatchVBios</key> <true/> <key>Inject</key> <dict> <key>Intel</key> <true/> <key>ATI</key> <true/> <key>NVidia</key> <false/> </dict> </dict> <key>KernelAndKextPatches</key> <dict> <key>AppleRTC</key> <true/> <key>AsusAICPUPM</key> <true/> <key>KextsToPatch</key> <array> <dict> <key>Name</key> <string>AppleAHCIPort</string> <key>Find</key> <data> RXh0ZXJuYWw= </data> <key>Replace</key> <data> SW50ZXJuYWw= </data> <key>Comment</key> <string>External icons patch</string> </dict> </array> </dict> <key>RtVariables</key> <dict> <key>MLB</key> <string>C02140302D5DMT31M</string> <key>ROM</key> <string>94DE80A3FDB2</string> <key>LogEveryBoot</key> <string>10</string> <key>LogLineCount</key> <integer>3000</integer> <key>MountEFI</key> <string>Yes</string> </dict> <key>CPU</key> <dict> <key>FrequencyMHz</key> <integer>3491</integer> <key>QPI</key> <integer>0</integer> <key>BusSpeedkHz</key> <integer>99768</integer> <key>Type</key> <string>1026</string> <key>C6</key> <true/> <key>Latency</key> <string>0X0</string> </dict> <key>SystemParameters</key> <dict> <key>BacklightLevel</key> <string>0x0000</string> <key>CustomUUID</key> <string>511CE200-1000-4000-9999-010203040507</string> <key>InjectSystemID</key> <true/> <key>InjectKexts</key> <string>Detect</string> </dict> </dict> </plist>   y este otro config plist es  con  la opción de la pestaña Gui custom , entries y kernel tildadas me sale el menú con los iconos de los discos duros  que detecta por scan + los que yo he añadido en custom..... <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>GUI</key> <dict> <key>CustomIcons</key> <true/> <key>Language</key> <string>es:0</string> <key>ScreenResolution</key> <string>1920x1080</string> <key>Theme</key> <string>iclover</string> <key>Mouse</key> <dict> <key>DoubleClick</key> <integer>400</integer> <key>Speed</key> <integer>4</integer> <key>Enabled</key> <true/> </dict> <key>Scan</key> <dict> <key>Entries</key> <true/> <key>Tool</key> <false/> <key>Legacy</key> <false/> </dict> <key>Hide</key> <array> <string>\EFI\BOOT\BOOTX64.EFI</string> </array> <key>Custom</key> <dict> <key>Entries</key> <array> <dict> <key>Path</key> <string>\EFI\BOOT\BOOTX64.EFI</string> <key>FullTitle</key> <string>Internal EFI</string> <key>Hidden</key> <true/> <key>Disabled</key> <false/> <key>InjectKexts</key> <false/> <key>NoCaches</key> <false/> <key>Type</key> <string>OSX</string> <key>VolumeType</key> <string>Internal</string> </dict> <dict> <key>Volume</key> <string>DBAFC65B-EC1E-3852-9B49-C7C8FAEB0EB9</string> <key>AddArguments</key> <string>-v npci=2000</string> <key>FullTitle</key> <string>OS X Mavericks</string> <key>Image</key> <string>/EFI/CLOVER/themes/iclover/icons/os_mav.icns</string> <key>DriveImage</key> <string>/EFI/CLOVER/themes/iclover/icons/vol_internal_hfs.icns</string> <key>Hidden</key> <false/> <key>Disabled</key> <false/> <key>InjectKexts</key> <false/> <key>NoCaches</key> <false/> <key>Type</key> <string>OSX</string> <key>VolumeType</key> <string>Internal</string> </dict> <dict> <key>Volume</key> <string>6A9DF3AE-5ADD-4060-B61D-3ED156B69043</string> <key>Path</key> <string>\EFI\Microsoft\Boot\bootmgfw.efi</string> <key>FullTitle</key> <string>Windows 7</string> <key>Image</key> <string>/EFI/CLOVER/themes/iclover/icons/os_win.icns</string> <key>DriveImage</key> <string>/EFI/CLOVER/themes/iclover/icons/vol_internal_ntfs.icns</string> <key>Hidden</key> <false/> <key>Disabled</key> <false/> <key>Type</key> <string>Windows</string> <key>VolumeType</key> <string>Internal</string> </dict> <dict> <key>Volume</key> <string>822BAC0C-AA6E-49FB-9CCA-78AB650152AE</string> <key>Path</key> <string>\EFI\Microsoft\Boot\bootmgfw.efi</string> <key>FullTitle</key> <string>Windows 8.1</string> <key>Image</key> <string>/EFI/CLOVER/themes/iclover/icons/os_vista.icns</string> <key>DriveImage</key> <string>/EFI/CLOVER/themes/iclover/icons/vol_internal_ntfs.icns</string> <key>Hidden</key> <false/> <key>Disabled</key> <false/> <key>Type</key> <string>Windows</string> <key>VolumeType</key> <string>Internal</string> </dict> <dict> <key>Volume</key> <string>0FC63DAF-8483-4772-8E79-3D69D8477DE4 </string> <key>Path</key> <string>\EFI\ubuntu\grubx64.efi</string> <key>FullTitle</key> <string>Ubuntu 13.10</string> <key>Image</key> <string>/EFI/CLOVER/themes/iclover/icons/os_linux.icns</string> <key>DriveImage</key> <string>/EFI/CLOVER/themes/iclover/icons/vol_internal_ext3.icns</string> <key>Hidden</key> <false/> <key>Disabled</key> <false/> <key>Type</key> <string>LinuxKernel</string> <key>Kernel</key> <string>All</string> <key>VolumeType</key> <string>Internal</string> </dict> </array> </dict> </dict> <key>Graphics</key> <dict> <key>InjectEDID</key> <true/> <key>PatchVBios</key> <true/> <key>Inject</key> <dict> <key>Intel</key> <true/> <key>ATI</key> <true/> <key>NVidia</key> <false/> </dict> </dict> <key>KernelAndKextPatches</key> <dict> <key>AppleRTC</key> <true/> <key>AsusAICPUPM</key> <true/> <key>KextsToPatch</key> <array> <dict> <key>Name</key> <string>AppleAHCIPort</string> <key>Find</key> <data> RXh0ZXJuYWw= </data> <key>Replace</key> <data> SW50ZXJuYWw= </data> <key>Comment</key> <string>External icons patch</string> </dict> </array> </dict> <key>SMBIOS</key> <dict> <key>BoardType</key> <integer>10</integer> <key>ChassisType</key> <integer>13</integer> <key>SmUUID</key> <string>9402de03-8004-a305-fd06-b20700080009</string> <key>BiosReleaseDate</key> <string>09/03/2013</string> <key>Version</key> <string>1.0</string> <key>SerialNumber</key> <string>C02KTIS1F8J3</string> <key>Manufacturer</key> <string>Apple Computer, Inc.</string> <key>BoardManufacturer</key> <string>Apple Computer, Inc.</string> <key>BoardSerialNumber</key> <string>C02140302D5DMT31M</string> <key>ChassisAssetTag</key> <string>iMac-Aluminum</string> <key>BiosVendor</key> <string>Apple Computer, Inc.</string> <key>ChassisManufacturer</key> <string>Apple Computer, Inc.</string> <key>BiosVersion</key> <string>IM141.88Z.0118.B00.1309031248</string> <key>Board-ID</key> <string>Mac-031B6874CF7F642A</string> <key>Family</key> <string>iMac</string> <key>ProductName</key> <string>iMac14,1</string> <key>LocationInChassis</key> <string>Part Component</string> <key>BoardVersion</key> <string>iMac14,1</string> <key>Trust</key> <true/> <key>Memory</key> <dict> <key>SlotCount</key> <integer>4</integer> <key>Channels</key> <integer>2</integer> <key>Modules</key> <array> <dict> <key>Slot</key> <integer>0</integer> <key>Size</key> <integer>4096</integer> <key>Frequency</key> <integer>1600</integer> <key>Vendor</key> <string>Kingston</string> <key>Part</key> <string>9905403-442.A00LF</string> <key>Serial</key> <string>0A02010C07080E0D</string> <key>Type</key> <string>DDR3</string> </dict> <dict> <key>Slot</key> <integer>2</integer> <key>Size</key> <integer>4096</integer> <key>Frequency</key> <integer>1600</integer> <key>Vendor</key> <string>Kingston</string> <key>Part</key> <string>9905403-442.A00LF</string> <key>Serial</key> <string>0A02010C0B070F0D</string> <key>Type</key> <string>DDR3</string> </dict> </array> </dict> </dict> <key>ACPI</key> <dict> <key>DSDT</key> <dict> <key>Debug</key> <true/> <key>ReuseFFFF</key> <false/> <key>SuspendOverride</key> <true/> <key>SlpSmiAtWake</key> <true/> <key>Name</key> <string>DSDT.aml</string> <key>Fixes</key> <dict> <key>AddDTGP_0001</key> <false/> <key>AddMCHC_0008</key> <false/> <key>FakeLPC_0020</key> <false/> <key>FixAirport_4000</key> <false/> <key>FixDarwin_0002</key> <false/> <key>FixDisplay_0100</key> <false/> <key>FixFirewire_0800</key> <false/> <key>FixHDA_8000</key> <false/> <key>FixHPET_0010</key> <false/> <key>FixIDE_0200</key> <false/> <key>FixIPIC_0040</key> <false/> <key>FixLAN_2000</key> <false/> <key>FixSATA_0400</key> <false/> <key>FixSBUS_0080</key> <false/> <key>FixShutdown_0004</key> <false/> <key>FixUSB_1000</key> <false/> <key>NewWay_80000000</key> <true/> <key>FixRegions_10000000</key> <true/> <key>FIX_RTC_20000</key> <true/> <key>FiX_TMR_40000</key> <true/> <key>AddIMEI_80000</key> <true/> <key>FIX_INTELGFX_100000</key> <false/> <key>FiX_WAK_200000</key> <true/> <key>DeleteUnused_400000</key> <true/> <key>FIX_ADP1_800000</key> <true/> <key>AddPNLF_1000000</key> <true/> <key>FIX_S3D_2000000</key> <true/> <key>FIX_ACST_4000000</key> <true/> <key>AddHDMI_8000000</key> <true/> </dict> <key>DropOEM_DSM</key> <false/> </dict> <key>DropTables</key> <array> <dict> <key>Signature</key> <string>DMAR</string> </dict> <dict> <key>Signature</key> <string>SSDT</string> <key>TableId</key> <string>CpuPm</string> </dict> <dict> <key>Signature</key> <string>SSDT</string> <key>TableId</key> <string>Cpu0Ist</string> </dict> </array> <key>PatchAPIC</key> <true/> <key>SSDT</key> <dict> <key>DropOem</key> <false/> <key>UseSystemIO</key> <true/> <key>Generate</key> <dict> <key>PStates</key> <true/> <key>CStates</key> <true/> </dict> <key>MinMultiplier</key> <integer>8</integer> <key>MaxMultiplier</key> <integer>35</integer> <key>EnableC6</key> <true/> <key>C3Latency</key> <string>0X0</string> </dict> </dict> <key>Boot</key> <dict> <key>Arguments</key> <string>-v</string> <key>DefaultVolume</key> <string>OS X Mavericks</string> <key>Legacy</key> <string>PBR</string> <key>Log</key> <false/> <key>Timeout</key> <integer>20</integer> <key>XMPDetection</key> <string>No</string> <key>Secure</key> <false/> </dict> <key>CPU</key> <dict> <key>FrequencyMHz</key> <integer>3491</integer> <key>QPI</key> <integer>0</integer> <key>BusSpeedkHz</key> <integer>99768</integer> <key>Type</key> <string>1026</string> <key>C6</key> <true/> <key>Latency</key> <string>0X0</string> </dict> <key>Devices</key> <dict> <key>Audio</key> <dict> <key>Inject</key> <string>898</string> </dict> <key>FakeID</key> <dict> <key>ATI</key> <string>0x0</string> <key>IntelGFX</key> <string>0x0</string> <key>NVidia</key> <string>0x0</string> <key>LAN</key> <string>0x0</string> <key>SATA</key> <string>0x0</string> <key>WIFI</key> <string>0x0</string> <key>XHCI</key> <string>0x0</string> <key>IMEI</key> <string>0x0</string> </dict> <key>UseIntelHDMI</key> <true/> <key>USB</key> <dict> <key>Inject</key> <true/> <key>FixOwnership</key> <true/> <key>AddClockID</key> <true/> <key>HighCurrent</key> <true/> </dict> </dict> <key>RtVariables</key> <dict> <key>MLB</key> <string>C02140302D5DMT31M</string> <key>ROM</key> <string>94DE80A3FDB2</string> <key>LogEveryBoot</key> <string>10</string> <key>LogLineCount</key> <integer>3000</integer> <key>MountEFI</key> <string>Yes</string> </dict> <key>SystemParameters</key> <dict> <key>BacklightLevel</key> <string>0x0000</string> <key>CustomUUID</key> <string>511CE200-1000-4000-9999-010203040507</string> <key>InjectSystemID</key> <true/> <key>InjectKexts</key> <string>Detect</string> </dict> </dict> </plist>   espero que me puedas ayudar y decirme donde esta el problema.......por cierto i placa tiene dsm, pero no se si lo tiene por defecto o se le puede desactivar lo mirare por si fuese eso...... pero dudo que sea eso DarwinDumper_log.txt
    bootlog_clover configurator.txt
    config.zip
    config2.zip
×