No.
Ni siquiera han lanzado el código fuente para los componentes específicos de ARM de libSystem, específicamente, la biblioteca matemática, que son casi todas las partes mágicas.
En el mejor de los casos, podría tener un núcleo Darwin en funcionamiento en una plataforma Android con mucho menos trabajo; un BeagleBoard sería una mejor opción en este momento, en realidad.
- ¿Cuáles son algunas de tus funciones ocultas y desconocidas favoritas en iOS 9?
- ¿Por qué Apple obliga a las personas a usar iTunes?
- ¿Existe alguna herramienta que sea capaz de automatizar llamadas de voz y SMS en iOS?
- ¿Qué significa iMessage de Apple para todas las empresas que ofrecen servicios de mensajería grupal o mensajes de texto gratuitos en iOS?
- ¿Cuál es la mejor aplicación de iOS para descargar MP3 con el fin de escuchar sin conexión?
Es solo el núcleo.
No es la gran cosa.
Personalmente he tenido un Raspberry Pi ejecutando un núcleo Darwin por un tiempo; No es tan difícil hacer la mayoría de las cosas, aunque dejé de hacer que DTrace funcionara, Apple no lo hizo.
Hace dos años que no toco el código. Probablemente tendría que cavar en una caja para encontrar la Raspberry Pi, en este punto (en realidad, estoy seguro de que tendría que cavar en una caja).
Obtener el locore y la ruta de la trampa y la VM y otro código no fue gran cosa, tenía FreeBSD como referencia para las partes ARM.
Supongo que las partes ARM64 serían geniales de ver.
Para poner en funcionamiento el resto de iOS, primero (obviamente) necesitará un núcleo.
Pero el resto de iOS no es realmente de código abierto suficiente para llegar a una GUI, como tampoco lo es el resto de Mac OS X.
No puede hacer los gráficos geniales, CoreVideo, etc., a menos que esté dispuesto a cometer muchas violaciones de derechos de autor para que ese código se ejecute en el espacio del usuario desde un iPhone con jailbreak.
El problema con el núcleo es que ARM tiene un problema real como plataforma de propósito general.
No hay ISA – Arquitectura estándar de la industria.
En una PC, arquitecturas IA32 e IA64, todos los dispositivos, excepto los gráficos, todos viven en el mismo lugar: puede usar el mismo código para ellos.
Es por eso que Linux tiene la abstracción, si puede llamarlo así; Creo que es un gran desastre, y es una de las razones por las que es difícil obtener código en una nueva plataforma de Android, o actualizar la versión de Android en una plataforma existente, de los llamados “archivos de placa”.
Parte del ímpetu para esto es que la comunidad Linux tiene una profunda desconfianza del “árbol de dispositivos” de OpenFirmware que se entrega al núcleo mediante u-boot, que es el cargador de arranque que está firmado criptográficamente y se carga mediante el arranque- cargador en ROM en los distintos núcleos ARM.
Todo esto se remonta a los días de PPC, cuando querían ejecutar Linux en el hardware de Apple, y descubrieron que no había una ID de CPU específica para cada CPU en el árbol de dispositivos, por lo que no podían fijar hilos a los núcleos.
Apple hizo esto porque no quería que los hilos se fijaran a un núcleo en particular; si, por razones de administración de energía, desea apagar uno o más núcleos, o, por razones térmicas, desea cambiar qué núcleos estaban encendidos, realmente no deseaba que el núcleo del sistema operativo se desatascara cuando los núcleos desaparecieran.
Linux, por otro lado, vivía principalmente en centros de datos, y la administración de energía no era un gran problema allí: en cambio, deseaba obtener todos los ciclos posibles de cada CPU posible, y quería (potencialmente) fijar ciertas cargas a Cierta CPU para evitar ataques de interferencia, como el almacenamiento en caché de fugas de información de una VM a otra.
Entonces, Linux quería desesperadamente tener una ID de CPU para poder fijar hilos a las CPU.
Y por lo tanto, para cada posible plataforma de Apple, copiarían el árbol de dispositivos de Apple, que incluía las diferencias de plataforma en el hardware y los chips U2 y U3, que se utilizaron para el control del bus, y así sucesivamente, y suministraron su propio Árbol de dispositivos que era sutilmente, o no tan sutilmente, diferente del árbol de dispositivos de Apple.
Entonces Linux creció esta “verruga”.
Y ninguna cantidad de Compound W ™ hará que esta verruga desaparezca: el kernel de Linux no confía en el árbol de dispositivos suministrado por el cargador de arranque para documentar adecuadamente el hardware en los controladores.
Y así, “archivos de tablero”.
El problema que surge de la mera existencia de un árbol de dispositivos separado, como si todos los sistemas ARM todavía estuvieran ejecutando Open Firmware y los “archivos de placa”, es que Linux tomó una mala decisión arquitectónica.
Esa decisión fue poner las diferencias específicas de la plataforma en el código, en lugar de extender el árbol de dispositivos lo suficiente como para proporcionar una descripción abstracta de los dispositivos en la plataforma ARM específica: generalmente un SoC.
Entonces, si tiene un Linux en ARM, no puede simplemente describir los dispositivos de manera abstracta en el árbol de dispositivos y, por supuesto, agregar cualquier controlador de hardware nuevo, como la vinculación de canales de 4 bits a 8 bits para el controlador de memoria para ciertos tipos de almacenamiento flash desde el que desea arrancar, para que las cosas arranquen el doble de rápido, etc.
Tienes que escribir un nuevo código para cada plataforma.
Ahora admito totalmente que mi propio Darwin-on-Raspberry Pi no usa la abstracción normal de Darwin / Mac OS X.
He codificado cosas que debería haber puesto en el PE ( experto en plataformas ). Pero solo quería subirlo a la única plataforma, y no me importaba, ya que lo hacía por diversión, no como una cosa para publicar.
Apple probablemente se habría quedado sin pegar, si lo hubiera publicado, y todavía estaría hasta el cuello en abogados, alegando que usé la Propiedad Intelectual de Apple obtenida mientras estaba en Apple, para hacer el puerto.
O, para usar una expresión estadounidense más colorida: Ass Deep In Alligators .
Pero no hay ninguna razón por la que no pueda mover el soporte de la placa a un módulo PE para Raspberry Pi.
Bueno, “podría con mucho escribir y maldecir en el JTAG”.
No creo que mucha gente del núcleo de Linux pueda hacer esto.
Ex ingenieros de kernel de Mac OS X / iOS, de varios equipos de CoreOS, sí.
Su mentalidad sigue siendo que debe agregar un montón de código con archivos de soporte de placa para cada plataforma, porque no puede confiar en el árbol de dispositivos que le entrega el gestor de arranque.
Y que desea “aplanar” el árbol de dispositivos en el proceso, y no agregar las anotaciones específicas de la plataforma necesarias para describir completamente el hardware, en el árbol de dispositivos, en lugar de incrustar mucho en los archivos de la placa.
En conclusión …
Si quieres tener todo iOS en plataformas Android en general?
Sí; buena suerte con eso, incluso si violaste los derechos de autor en todas las otras piezas de iOS, seis maneras desde el domingo, y las sacaste de un iPhone con jailbreak para hacerlo.
Simplemente no va a suceder, a menos que algunos empleados actuales o anteriores de Apple extiendan el nuevo código escribiendo PE de referencia para, por ejemplo, Raspberry Pi, y tal vez un par de plataformas BeagleBoard, y tal vez un teléfono Android.
No.
