¿No es Android un kernel común que se usa en todos los dispositivos? Por ejemplo, CentOS se instalará en Dell, HP y una variedad de otros hardware. Claro que hay diferentes módulos, pero aún así es CentOS.
¿Cuál es la razón por la que CyanogenMod siempre está "roto"? Siempre escucho en los foros que están trabajando para portar este controlador o ese controlador. Si usaran el mismo kernel, ¿no funcionarían los controladores con él? También veo un millón de tipos diferentes de núcleos para diferentes dispositivos.
Los núcleos varían de un fabricante a otro. Muchos de esos kernels provienen de la línea de fuentes de kernel de stock puro que se encuentran en CAF, lo que hacen estos fabricantes es tomar esas fuentes de stock, modificarlas para adaptarlas en función de la placa/chipset utilizado, además, implementar sus propios controladores.
Mire bien a su alrededor, hay variaciones de pantallas táctiles, variaciones de conjuntos de chips wifi, sin mencionar, acelerómetro, sensores, baterías, brújula, sonido, gráficos.
Tomar una fuente de kernel de, por ejemplo, HTC no funcionará en un Samsung, y viceversa.
Los fabricantes son libres de elegir o subcontratar varios bits que se incorporan a la placa de circuito. No hay reglas duras o rápidas involucradas. De ahí la gran cantidad de piratería / modificaciones para que el núcleo funcione correctamente.
Nunca debe comparar con los núcleos de distribución de Linux de escritorio en los que tiene PCI, PCI-Express, SATA, VGA, SVGA, USB, Ethernet, ya que son un juego de pelota totalmente diferente. Las principales diferencias con CentOS y con el kernel de Linux de Android son las siguientes: TODOS los controladores se compilan como módulos o integrados, por lo tanto, cualquier distribución de Linux simplemente "funcionará de inmediato". Nuevamente, con las distribuciones de Linux de escritorio, tiene una arquitectura, x86, por lo tanto, un kernel de Linux de, por ejemplo, una PC Dell, puede funcionar de inmediato en una Lenovo siempre que se compilen los controladores estándar de bog.
No olvide, en el mundo de Android, hay variaciones del kernel creadas para conjuntos de chips ARM específicos, como ARMv6, ARMv7, TEGRA, EXYNOS, y son incompatibles binariamente entre sí. Por lo tanto, si se compila un núcleo para TEGRA, olvídelo, ¡no funcionará en ARMv7!
La razón por la que algunos núcleos de Android parecen estar "rotos" se debe al fabricante. Algunos (Zte es un muy buen ejemplo) lanzan una fuente eliminada que puede compilar desde la fuente pero no se inicia debido a la falta de un controlador que no está cubierto por la licencia GPLv2 o GPLv3. Ese es el problema, por lo tanto, algunos piratas informáticos tienen que recorrer github en busca de algunas pistas; algunos fabricantes, si no todos, cumplen. Supuestamente, la encarnación actual de la fuente de Zte es 2.6.35.7, pero en realidad su fuente base es 2.6.32.9 con muchas modificaciones, por lo que no representa la verdadera fuente del kernel para 2.6.35.7.
Aquí es donde los fabricantes tienen que publicar sus fuentes respectivas, no solo para cumplir con GPLv2 o posterior, sino para que la comunidad pueda modificarlo, como agregar capacidades de overclocking.
Por lo tanto, hay piratería detrás de escena y muchos problemas con los controladores que intentan que funcione, y tampoco es fácil de depurar. Algunos controladores pueden tener licencias cruzadas, PERO no se pueden distribuir según la cláusula y las condiciones como negociado
Afortunadamente, todo eso cambió ahora con la línea de fuentes kernel 3.xx, ya que los controladores de Android ahora están integrados en las fuentes principales. ¡Pero hay un problema!
Intente portar un kernel 3.xx a un teléfono existente que tenga entre 12 y 18 meses; No funcionaría ni en el infierno, eso se debe a que, de los diferentes factores, las fuentes 3.xx son muy diferentes a la fuente 2.6.x y se necesitaría mucha piratería para que funcione. Debería saberlo, lo he intentado. portar la fuente 2.6.38.6 para el Zte Blade y falló.
Del mismo modo, la última versión del kernel 3.0.1: cuando trabajaba en el proyecto ics4blade en Modaco, hizo numerosos intentos de portarlo, pero eso se debe al simple hecho de que Zte hizo un gran lío con la fuente, lo que hizo que la portabilidad fuera casi imposible. .
La arquitectura de la PC se basa en piezas básicas porque comenzó como clones de un producto específico, la PC de IBM, que se diseñaron específicamente para ser compatibles con ella y, por lo tanto, entre sí. En términos generales, puede tomar un programa o dispositivo periférico de una PC compatible y ponerlo en otra, y esperar que funcione. Esa capacidad es lo suficientemente útil como para que la gente continúe exigiéndola incluso a medida que la tecnología evolucionó. Puede poner una tarjeta PCI Express en cualquier PC moderna de la misma manera que podía poner una tarjeta ISA en cualquier clon de PC en ese entonces.
Los teléfonos inteligentes no tienen tal historia. Están diseñados como productos monolíticos, un sistema completo que consta de hardware y software que "simplemente funciona" tal cual. No se espera que las personas extraigan partes de un teléfono y las coloquen en otro, por lo que los ingenieros no tienen que tener en cuenta la interoperabilidad cuando diseñan sus productos.
Incluso dentro del árbol de fuentes del kernel de Linux, hay mucha fragmentación en los controladores para las plataformas ARM . Dado que los teléfonos generalmente se diseñan a puertas cerradas, los equipos de ingeniería de diferentes empresas a menudo terminan haciendo un trabajo duplicado, diseñando básicamente el mismo hardware que sus competidores y luego escribiendo sus propios controladores para su propio diseño. Una vez que terminan y se lanza el producto, pasan directamente a trabajar en el siguiente; no vale la pena volver atrás y refactorizar los controladores de productos anteriores o fusionarlos con los controladores de la competencia. El resultado es una plétora de controladores únicos para dispositivos que son similares pero no exactamente iguales.
Además, los teléfonos inteligentes generalmente se basan en SOC que tienen hardware especializado integrado junto con el procesador. Para algo de esto, puede ser más que una cuestión de cargar o no cargar un determinado controlador; Es posible que el núcleo en su conjunto deba construirse con opciones de configuración especiales para ejecutarse en un SOC, que son incompatibles con las opciones especiales necesarias para ejecutarse en otro SOC.
La razón es que el kernel de Linux de Android generalmente no se compila en el propio Android, sino que tuvo que compilarse de forma cruzada desde otra computadora. Esto causa varios problemas, porque la configuración del dispositivo no está disponible en tiempo de compilación y no es factible compilar un núcleo genérico con todos los controladores debido a la limitación de espacio (mientras que la mayoría de las distribuciones de escritorio simplemente tenían todos los controladores compilados en módulos cargados desde un initramfs) . Por lo tanto, los desarrolladores tuvieron que averiguar qué controladores empaquetar para cada dispositivo en particular. No solo eso, cada controlador generalmente tiene una docena o más de opciones de tiempo de compilación para alternar varias características del controlador, y los fabricantes generalmente no publican su configuración oficial (los peores infractores ni siquiera abren sus controladores o no mantuvieron la configuración original). copia de los drivers al día).
La programación de controladores es mucho más difícil que la programación de aplicaciones, ya que no existe un kernel que lo proteja del hardware inconstante que tiene requisitos específicos de tiempo en tiempo real y demás, y esto significa que incluso tener una característica de rendimiento diferente puede hacer que el controlador falle. algunos eventos duros en tiempo real del hardware; estos fallos pueden surgir como errores o problemas de rendimiento.
Otro problema es la incompatibilidad binaria. Hay dos causas de incompatibilidad binaria, primero es el tipo de CPU, que ha sido cubierto bien por t0mm13b, pero el otro problema que es más relevante para la migración es la incompatibilidad ABI (interfaz binaria de la aplicación). Si los fabricantes no abren sus controladores, entonces los desarrolladores tenían que usar el módulo compilado de una ROM estándar. Esto plantea varios problemas de incompatibilidad de ABI, ya que los módulos del controlador en sí tienen expectativas específicas sobre, por ejemplo, el diseño de la estructura y los parámetros de llamada de funciones, y cuando se compila el kernel, no tiene el archivo de encabezado para describir el ABI en el momento en que el controlador se compila, por lo tanto, los desarrolladores tuvieron que aplicar ingeniería inversa al controlador para crear un archivo de encabezado o los archivos de encabezado en el árbol de origen podrían haberse modificado en gran medida ya que el controlador está compilado y los desarrolladores tuvieron que revertir esas modificaciones para que el kernel fuera compatible nuevamente con el ABI del controlador. A diferencia de la compilación desde la fuente, la compilación para el controlador binario no generará un error de compilación debido a la falta de coincidencia de los parámetros de la función o la incompatibilidad de la estructura, simplemente bloqueará su dispositivo mientras se está ejecutando, y la depuración de estos problemas es muy difícil. En el mundo de las PC, estamos familiarizados con el lío que nos dejaron nVidia y ATi, debido a su insistencia en lanzar controladores binarios solamente, imagina tener ese lío para todos los controladores, imagina la "diversión" que crea.
El hardware de la PC también está generalmente mejor estandarizado que el hardware móvil, la mayoría de las PC no necesitan controladores para vibradores, acelerómetros, giroscopios, radio 3G, sensor de proximidad, NFC, etc. Incluso en dispositivos que tienen 3G, generalmente se conecta al hardware usando conexiones como PCMCIA o PCI-E.
Bueno... los drivers y el kernel no son exactamente iguales.
Los controladores son los que controlan la antena celular, wifi, bluetooth, etc. Estos son controladores propietarios porque el fabricante tiene que crear una forma (los controladores) para comunicarse con su hardware.
El kernel es un nivel intermedio entre el sistema operativo/aplicación y los controladores reales (o CPU, memoria o cualquier otro hardware). Es lo que permite que su sistema operativo/aplicaciones interactúen con estos componentes de hardware.
Todos los millones de núcleos que ves en realidad no son muy diferentes entre sí. Por lo general, un programador/modder tomará el núcleo existente y lo "ajustará" para intentar obtener un rendimiento diferente. Esencialmente, puede decir que solo están ajustando (en su mayor parte) la "configuración" del kernel. En el mundo de Android, estos modders buscan principalmente: overclocking o underclocking del reloj de la CPU (importante para ahorrar batería o intentar ejecutar la mayoría de las aplicaciones intensivas en procesos, como emuladores de videojuegos o reproducción de video), o están buscando under- Voltaje (para ahorrar batería al hacer funcionar su CPU fuera de sus parámetros establecidos originalmente... que varía en efecto de persona a persona porque no hay dos CPU hechas 100% exactamente iguales).
Los teléfonos y otros sistemas integrados no tienen un BIOS para proporcionar abstracción entre el hardware y el sistema operativo, como resultado, el sistema operativo se compila para el hardware en el que se implementa. Incluso los dispositivos que usan el mismo conjunto de chips pueden configurarse de diferentes maneras (usando buses de comunicación alternativos, etc.) \el resultado es que el núcleo debe compilarse en consecuencia. Como no se esperan cambios en el hardware, no se realiza ninguna detección de hardware. Kernel arranca más rápido y, como resultado, es más pequeño: este es un principio estándar de un sistema operativo integrado
CentOS se instala en un hardware diferente, pero,
En cuanto a su segundo punto, vea las respuestas publicadas anteriormente.
usuario974896
t0mm13b