linux ido mal

He estado hackeando el núcleo Linux para hardware embebido (principalmente PDAs)
por un buen rato ya y estoy harto de la mierda que
OEMs seguir haciendo. Es por eso que he decidido poner esta diatriba sobre algunos
fallas comunes que se encuentran en el código de OEM y algunos consejos para programadores OEM / gerentes
sobre cómo reducir los costes de desarrollo y mejorar la calidad de su código.

Versión corta: no sufren NIH ser amigable con la comunidad.
Versión larga está por debajo. Es posible que sea usted editado a ser más corto y voy a añadir más puntos a la misma

MSM / QSD árbol del núcleo queda gravemente detrás estilo
tanto kernel vainilla y google árboles , y hasta hace poco (cuando el
arquitectura fue re-diseñado para ser más API abiertas y estándar como ALSA reemplazados algunos
bits de propietarios) cualquier versión Android importante (como Gingerbread) significaron
HTC, Sony Ericsson y otros infelices almas encantadas por Qualcomm tenido />
hay buenos ejemplos como Samsung y Texas Instruments
cuya SoC haber todo el código mainlined, incluidos los conductores v4l2 para la cámara y
ALSA para el audio. Y hay los que comenzaron como Qcom y rodó fuera
un lío de código BSP cutre, pero luego se dio cuenta de que es mejor que jugar con las reglas />
—— Ok, vamos a llegar al segundo nivel – productos terminados y de códigos OEM.
A juzgar por el código podemos ver lanzado públicamente,
no hay convenciones de código, sin control de código fuente. Hay toneladas de # ifdeffery
y duplicar código. Ese no es el problema en sí, eso es sólo el resultado
de la falta de cultura de desarrollo

Algunos ejemplos notables que me hacen loco
Qualcomm / HTC:.. Ignorando totalmente las interfaces existentes para la fuente de alimentación,
reguladores. Reimplementar el código existente (en su mayoría copiar y pegar). Esto lleva
a los problemas de mantenibilidad

Asus [TF101]:. Vez de utilizar datos de la plataforma, decidieron cortar hasta
los controladores existentes y agregar código directamente a GPIO / mmc / . controladores de sonido

Samsung [Galaxy S2]:. muchos conductores duplicados para la misma pieza de hardware /> Ranting debe ser productivo. Por lo tanto, a continuación voy a escribir una lista de consejos
sobre la forma de escribir y mantener código en determinados subsistemas y dar
una breve justificación para que no suena como gemidos de un geek hardware.

general
– lanzamiento temprano, la liberación a menudo, empuje el código de aguas arriba />
problemas conseguirán detectado en etapas anteriores. Usted no va a terminar
con varias versiones de código mutuamente incompatibles

-. No use el mismo tipo de máquina para todas las tarjetas . Registre una con />
Fundamento:. El tipo de máquina se introdujo para permitir tener una
kernel soporte binario varias tarjetas. Cuando un vendedor hardcodes el mismo tipo de máquina /> ​​
un solo núcleo para estos dispositivos y hace que el mantenimiento de kernel difícil.
Por lo tanto, este tipo de código no es aceptadas aguas arriba y apoyo a las nuevas versiones
cuesta más esfuerzos de desarrollo

– Evite tiempo de compilación # ifdef, especialmente en BBcode
Fundamento:. que evitar que varias tarjetas que se construya una sola imagen de kernel />
tiende a romperse. . Por lo tanto, el uso de tipo de máquina o la revisión del sistema
para seleccionar la ruta de código en tiempo de ejecución

– No utilice no estático ‘extern’ llama Si en sentido estricto. . necesarios, declaraciones uso />
Justificación: esto agrega un nivel adicional de cheques puntero NULL y
mejora la estabilidad y la seguridad />
– No lo hagas. reinventar lo que ya se implementó
Fundamento: el código no lo acepten aguas arriba. Su código se
no recibir de errores y parches de seguridad cuando alguien corrige fallas aguas arriba.
Usted perderá tiempo portarlo entre las versiones del kernel. Voy a escribir
una perorata acerca de usted. Si necesita alguna funcionalidad faltante aguas arriba,
por favor, envíe un parche para que la lista de correo y fijar aguas arriba en vez
de copiar y pegar />
-. No lo hagas contaminar el código fuente con el código # ifdef muertos, comentarios
de antiguos sistemas de control de versiones propietarias . . No seguir las convenciones de código
Justificación: esto facilita a la comprensión de su código y su mantenimiento

– repositorios de control de uso en la versión pública
Fundamento..: esto permite a los programadores de otros fabricantes para encontrar parches para correcciones de errores específicos /> de mantenerse al día con la corriente arriba y mejora la calidad del código.

– No trate de ocultar el código
Justificación: lo que usted va a terminar con es que el conductor no
obtener aguas arriba, los aficionados van a culpar a usted por todos los pecados mortales,
usted tendrá que reparar su basura cada lanzamiento.

controlador ISP (tubería de captación de imágenes, cámara de vídeo) <. br /> – Uso V4L2
API Justificación: puede empujar al conductor contra la corriente, vuelva a utilizar la cámara con sensor
controladores ya aguas arriba, reutilización bibliotecas de espacio de usuario y aplicaciones de procesamiento de vídeo />

Fuente de alimentación (baterías, cargadores)
– Uso conductor pda_power />
Reimplementar, incluyendo fuente de alimentación de monitoreo usb / ac y notificar
batería conductores

drivers de sonido
-. Uso Alsa. No utilice IOCTLs personalizados
Fundamento:. Usted podrá volver a utilizar las librerías de sonido de entorno de usuario existentes y
conductores codec de nivel de núcleo

Así que, ¿qué . que quiero ver es un dispositivo terminado , como un teléfono, una tableta, que