Traducido desde : https://www.haiku-os.org/community/getting-involved/developing/system/
Áreas del proyecto
Conductores
Kernel / Sistemas de archivos
Medios de comunicación
Red
Interfaz de usuario
Conductores
Soporte USB para la capa de compatibilidad de red FreeBSD
Haiku usa una capa de compatibilidad de red FreeBSD para admitir muchos dispositivos de red (Ethernet e inalámbricos) que usan controladores escritos para el proyecto FreeBSD. Esto permite reutilizar los controladores de red con muy pocos cambios, lo que reduce considerablemente el esfuerzo necesario para obtener un buen soporte de hardware en Haiku. Sin embargo, esta capa solo admite dispositivos PCI y no funciona con dispositivos USB. Agregar soporte para USB a la capa de compatibilidad nos brindaría soporte para una gama de dispositivos como el llamado USB, así como también dispositivos USB a Ethernet y dongles WiFi.
Este proyecto consiste en importar uno o más controladores de red USB de FreeBSD a las fuentes de Haiku. La capa de compatibilidad debe extenderse para exponer las API USB de FreeBSD a los controladores y reenviar las llamadas a la pila USB de Haiku. Otras partes de las capas de compatibilidad pueden necesitar ser extendidas también.
Red de virtio y drivers de globos.
Virtio ("entrada y salida virtual") es una tecnología utilizada en máquinas virtuales para reducir la sobrecarga de emulación. En lugar de simular un dispositivo existente, las máquinas virtuales exponen un dispositivo "virtio" simplificado, que está diseñado para facilitar la interconexión entre el huésped y el sistema host. La tecnología se aplica actualmente a los discos, la memoria y la red. El controlador de memoria virtio permite implementar un "globo", es decir, la máquina virtual puede aumentar o disminuir su uso de la memoria (como un globo está inflado o desinflado) cuando el sistema huésped asigna o libera memoria. Esto facilita compartir la memoria entre varias máquinas virtuales de manera más eficiente.
Haiku ya tiene un controlador de bus virtio y un controlador de disco virtio. La adición de un controlador de tarjeta de red virtio y un controlador de globo de memoria virtio permitiría a Haiku aprovechar las aceleraciones de emulación utilizando el bus virtio liviano. Haiku también podría implementarse en entornos como Amazon S3 u OpenStack.
Entradas: # 9800 controlador de red virtio , # 9803 controlador de memoria de globo virtio
Código existente: controlador de red virtio (objetivo de esta tarea) , controlador de bus virtio (debe estar casi completo) , bloque virtio (funcional, ejemplo de uso de virtio bus)
Extensiones de video ACPI
Las Extensiones de Video ACPI, como se especifica en el Apéndice B de la Especificación ACPI 4.0a, agregan soporte especial para manejar múltiples dispositivos de salida, como paneles y capacidades de salida de TV, control de brillo, así como funciones especiales de administración de energía.
Soporte AV / 1394
Nuestra pila Firewire admite la recepción de DV, pero no controla el dispositivo A / V (es decir, reproducir / detener). Esto requiere modificar la pila Firewire para el soporte de cuadros FCP. Consulte la especificación general del conjunto de comandos de la interfaz digital AV / C para referencia.
Mejoras de pila USB (USB3, transferencias isócronas)
Como cualquier otro sistema operativo, Haiku tiene controladores para todos los tipos de interfaces USB: OHCI y EHCI para USB1, UHCI para USB2 y XHCI para USB3. Sin embargo, la mayoría de estos aún necesitan algunas mejoras para mejorar la compatibilidad y agregar soporte completo de la especificación USB. El soporte de XHCI aún no está completo. En varias máquinas no detectará dispositivos, generará muchas interrupciones de hardware o incluso evitará que todo el sistema arranque. El trabajo en el soporte de XHCI debe continuar para que Haiku obtenga un soporte más confiable y completo para USB3. El USB permite 3 formas diferentes de intercambiar datos con un dispositivo: volumen, interrupción e isócrono. En modo masivo, los datos se transfieren cuando el bus está inactivo. El modo de interrupción tiene mayor prioridad. Finalmente, el modo isócrono garantiza una tasa mínima. Este último modo se usa, por ejemplo, mediante tarjetas de audio USB y cámaras web, ya que necesitan un flujo constante de datos a una velocidad fija. A los controladores UHCI y EHCI les falta la compatibilidad con las transferencias USB isócronas. Esto hace que sea imposible utilizar la mayoría de las tarjetas de sonido USB y cámaras web en Haiku. Las tareas de USB consisten en implementar un soporte completo de USB3 o transferencias isócronas para dispositivos USB1 y USB2. Esto puede complementarse con la transferencia de una cámara web o un controlador de tarjeta de audio desde FreeBSD o Linux (se prefiere FreeBSD debido a la licencia de software utilizada, preferimos evitar el código GPL si es posible).
Ticket para soporte de flujos isócronos USB.
Soporte de unidad de disquete
Todavía no soportamos disquetes
Soporte de SD Host Controller
Haiku actualmente no tiene soporte para SD Host Controller. Implementar una pila con soporte para dispositivos PCI SDHC sería un buen comienzo. Esto implicaría diseñar y desarrollar un controlador de bus PCI SDHC, un módulo de bus MMC y un controlador de disco SD MMC.
Para desarrollar y probar, QEmu (a partir de 2.3) proporciona una emulación para SDHC en PCI: -dispositivo sdhci-pci -sd my-test-drive
Especificaciones para SDHC
Especificaciones para MMC
Referencias QEmu
Soporte de aceleración 3D
Haiku no admite actualmente la aceleración de hardware de la representación 3D. Utilizando la infraestructura de Gallium de Mesa, el objetivo de este proyecto es hacer que el renderizador Mesa existente permita la representación 3D y no solo el software. Esto implica extender la API utilizada por nuestros controladores de video (que actualmente solo está orientada en 2D) y hacer que Gallium use esa API. Algunas partes del modelo DRI / DRM utilizado en Linux pueden ser reutilizables, pero la cooperación con app_server debe ser posible.
Puerto Nouveau / PSCNV
Haiku actualmente no tiene un controlador para tarjetas de video NVidia, y recurre a VESA para esas. Si bien nuestro controlador VESA es razonablemente rápido, no puede establecer la resolución nativa en todos los sistemas, lo que lleva a una experiencia subóptima de Haiku. Nouveau es un controlador de gráficos para tarjetas de video NVidia. Hay una bifurcación llamada PSCNV que podría tener menos dependencias en Linux. cf. https://github.com/pathscale/pscnv/wiki
Núcleo
Gestor de arranque
BootManager debe actualizarse para que sea compatible con varias unidades o debe reemplazarse.
Cargador de arranque UEFI x86-64
Haiku actualmente carece de un cargador de arranque UEFI. El código para hacer que Haiku construya una aplicación UEFI con la plataforma de arranque ya existe. Necesitará escribir el código de inicio real que configura la CPU para iniciar Haiku. Para su ayuda, tiene el código de inicio para BIOS x86 / x86-64 y la depuración en serie con printf. El desarrollo se puede hacer en QEMU con firmware UEFI y salida en serie. La API de UEFI es muy simple y se aprendió rápidamente; la habilidad principal necesaria es el arranque de la plataforma x86-64. Esto no tiene que incluir el arranque seguro.
El código Haiku para cargar el kernel se encuentra en src / boot / platform. Puedes ver las diferentes implementaciones. La versión de EFI en ese árbol construye el código de plataforma de inicio, puede ejecutarse como una aplicación de EFI, puede llamar a funciones de EFI, pero no mucho más. Lo que se debe hacer es configurar la CPU, MMU, manejar los argumentos del kernel, cargar el kernel, algunos controladores (al menos Vesa) que usan las funciones del BIOS necesitan desactivarse. Básicamente, todo lo que se necesita para configurar y arrancar una plataforma x86_64 una vez que se inicia la aplicación EFI falta. Las herramientas de Userland para EFI también faltan, por lo que la modificación y la visualización de las opciones de arranque también podrían ser parte del proyecto. Necesitaría un controlador para los servicios de Runtime y una aplicación para establecer / obtener variables.
Información Adicional:
Nuestro GNU EFI simplificado (bueno para aprender UEFI / QEMU): https://github.com/tqh/efi-example
Árbol de desarrollo de EFI actual (consulte el historial de confirmación y las instrucciones de compilación )
Información de la API de UEFI: http://wiki.phoenix.com/wiki/index.php/Category:UEFI_2.1
Gestion de energia
Haiku ya tiene algún soporte de administración de energía en forma de un controlador de CPU en ralentí. Sin embargo, esto claramente no es suficiente, y hay espacio para mejoras en varias áreas con el fin de hacer que Haiku use menos energía y que las computadoras portátiles con Haiku duren más en la batería.
Se requiere cierta investigación para identificar los problemas principales en Haiku que conducen a un rendimiento subóptimo. Sin embargo, hay algunos problemas ya conocidos:
Algunos subsistemas, como la red y la pila inalámbrica, activan el sistema a intervalos regulares (10 o 100 veces por segundo) para realizar algunas tareas. Siempre que sea posible, deben modificarse para desencadenar estas tareas de forma controlada por un evento (por ejemplo, desencadenarlas desde interrupciones de hardware).
Algunas aplicaciones (como la DeskBar que siempre se está ejecutando) sondean eventos de una manera similar. Las API deben ajustarse donde sea posible para que esas aplicaciones esperen notificaciones en su lugar.
Ninguno de los controladores de dispositivos en Haiku incluye modos de ahorro de energía. Cuando un dispositivo está inactivo, debe ponerse en reposo y apagarse hasta que sea necesario nuevamente.
Sistemas de archivos: Nuevo HaikuFS para reemplazar BFS
Enlace a la idea en el wiki devopment.
Sistemas de archivos: soporte de escritura para más sistemas de archivos
Haiku tiene un gran soporte para su propio sistema de archivos, pero la mayoría de los otros solo están disponibles en modo de solo lectura. Es mucho mejor que la interoperabilidad con otros sistemas pueda escribir en estos discos desde Haiku.
El objetivo de este proyecto es completar el soporte existente para uno de los siguientes sistemas de archivos en Haiku, trabajando desde la base de código existente:
ReiserFS fuentes existentes , especificaciones oficiales , documentación adicional en el diseño de FS
BTRFS: código existente , página de inicio
Sistemas de archivos: mejoras generales y nuevos sistemas de archivos.
Haiku tiene un gran soporte para su propio sistema de archivos, pero falta completamente el soporte para algunos otros sistemas fiel. Es mucho mejor que la interoperabilidad con otros sistemas pueda leer y escribir en estos discos.
El objetivo de este proyecto es portar uno de los siguientes sistemas de archivos a Haiku:
ext4: extienda el controlador ext2 existente para admitir las nuevas funciones ext3 y ext4
UFS2 (como se usa en * BSD): implementación de FreeBSD , u2fstools para Windows (BSD con licencia, la fuente se puede reutilizar)
HAMMER FS: página de inicio , código fuente (BSD de 3 cláusulas, un puerto del código existente está bien)
JFS : el código existente en Linux está bajo la GPL, se prefiere una reescritura bajo la licencia MIT. El diseño del sistema de archivos y las estructuras de disco están bien documentados.
XFS : comunidad de desarrollo , página de inicio (el código existente en Linux está bajo la GPL, se prefiere reescribir bajo la licencia MIT)
ZFS : página principal , código existente (el código existente está bajo la CDDL, se prefiere reescribir)
SMB , Windows comparte: smbfs de FreeBSD (BSD de 2 cláusulas, el código se puede portar a Haiku)
Está bien transferir el código de otros sistemas, aunque preferimos el código que puede distribuirse bajo la licencia MIT.
IMAP FS: acceso del sistema de archivos a una cuenta IMAP
En Haiku, los correos electrónicos se almacenan como un archivo individual con atributos extendidos . El protocolo IMAP expone los correos en una jerarquía de carpetas y permite "navegar" en un buzón de correo remoto. Montar una cuenta IMAP como un sistema de archivos local es, por lo tanto, un ajuste natural. El sistema de archivos debe tener soporte completo de lectura y escritura (eliminar correos (archivos), crear carpetas y mover correos entre carpetas, etc.) con almacenamiento en caché local para un mejor rendimiento. El diseño de las implementaciones de netfs y nfs4 para Haiku, así como las googlefs más simples, pueden servir como una referencia sobre cómo implementar un sistema de archivos de red.
x86-64: Soporte para usuario de 32 bits
Haiku está disponible actualmente en versiones de 32 y 64 bits. Sin embargo, la versión de 64 bits actualmente no puede ejecutar aplicaciones de 32 bits, lo que obliga a los desarrolladores de aplicaciones a proporcionar una versión de 64 bits de sus aplicaciones. Esto está reduciendo la adopción de las versiones de 64 bits de Haiku por falta de aplicaciones disponibles.
El objetivo de esta tarea es agregar un modo de compatibilidad al kernel de 64 bits para que pueda ejecutar programas de 32 bits. Los problemas al hacer eso implican ajustar los parámetros de syscall y, principalmente, convertir los punteros desde la zona de usuario de 32 bits al direccionamiento de 64 bits utilizado en el lado del kernel. Las aplicaciones de 32 bits compiladas para Haiku "x86" deben ser compatibles. El manejo de aplicaciones BeOS heredadas compiladas con gcc2 también puede considerarse como un objetivo extendido, pero no tan importante.
Soporte ARM puerto / dispositivo de árbol
A diferencia de los sistemas x86 que tienen un bus PCI, la mayoría de los dispositivos ARM tienen periféricos en direcciones codificadas. Esto significa que el descubrimiento automático de hardware no es posible. Los desarrolladores del kernel de Linux diseñaron una solución llamada "árbol de dispositivos aplanado". Es una descripción estática del hardware, que indica al núcleo dónde se encuentran los dispositivos y qué controlador usar.
Haiku planea usar árboles de dispositivos para admitir varios dispositivos ARM con el mismo núcleo. Esto requiere actualizar nuestros controladores y nuestra infraestructura de controladores para no depender tanto del bus PCI. Este trabajo debe comenzar con el controlador EHCI USB, para proporcionar al menos una solución de almacenamiento masivo al puerto ARM de Haiku.
El puerto ARM de Haiku se encuentra actualmente en un estado temprano. Este proyecto puede implicar la depuración de otros problemas en el puerto para que siga funcionando, por lo que se puede probar la parte del árbol de dispositivos. Deben revisarse varias partes del código de inicio temprano para hacer uso del árbol de dispositivos y eliminar las direcciones codificadas (asignación de RAM, framebuffer, puerto serie, etc.).
Unificar los cachés del sistema de archivos
El kernel de Haiku proporciona dos tipos de cachés para uso de las implementaciones del sistema de archivos: el caché de archivos y el caché de bloques . La memoria caché de archivos almacena en caché los datos en el nivel de "archivo", mientras que la memoria caché de bloque se utiliza en el nivel de "bloque" y se utiliza para las estructuras en disco así como para los datos de archivos.
La memoria caché de archivos utiliza las páginas de memoria física directamente y está vinculada con el subsistema VM , de modo que las páginas utilizadas para el almacenamiento en caché se liberan automáticamente (en un orden menos recientemente utilizado) cuando se está agotando la memoria libre. Sin embargo, la memoria caché de bloques utiliza la memoria asignada (a través del asignador de la losa ) y la liberación de memoria en situaciones de poca memoria se maneja a través del administrador de recursos bajos .
El primer problema con la implementación actual es el desequilibrio del almacenamiento en caché en favor de la memoria caché de bloques: tiende a crecer más de lo necesario y evita que la memoria caché de archivos obtenga suficiente memoria.
Otro problema es el uso de grandes cantidades de espacio de direcciones del kernel por el caché de bloques, que puede ser problemático en arquitecturas de 32 bits. Esto hace que la memoria caché de bloques se limite a los 2 GB de memoria disponibles para el kernel en Haiku, y algunas veces hace que el kernel se quede sin espacio de direcciones para otros usos.
El objetivo de este proyecto es crear un mecanismo subyacente común (utilizando `VMCache`) para unificar ambos cachés y mover el caché de bloques fuera del espacio de direcciones del kernel. Los siguientes problemas deben ser investigados y resueltos:
Cómo lidiar con los tamaños de bloques heterogéneos (que no necesariamente coinciden con el tamaño de la página): cada volumen de sistema de archivos montado puede tener un tamaño de bloque diferente, y la memoria caché de bloques debe poder almacenar de manera eficiente bloques de estos tamaños diferentes,
Cómo asignar soporte para transacciones a jerarquías `VMCache`,
Equilibrio de la asignación de memoria entre el bloque y el caché de archivos y entre múltiples volúmenes de sistemas de archivos montados.
Reemplace el código GNU con eso bajo licencia permisiva
Reemplace la biblioteca y utilidades de GNU C con equivalentes con licencia BSD
Gestion de sesion
Soporte multiusuario
Red
Mejoras de Bluetooth Stack
Haiku Bluetooth Stack implementa solo una funcionalidad básica en las capas inferiores y medias. Esta funcionalidad debe completarse y se deben explorar las posibilidades de Bluetooth 2.X y posteriores. Esta tarea implica investigar el estado actual del código Bluetooth, verificar que la funcionalidad básica aún funciona (emparejar dispositivos, etc.) y mejorar la pila para que sea más útil al implementar controladores para un dispositivo Bluetooth de su elección (audio, HID). , redes, etc).
Integrar nuestra implementación PPP.
Portar la implementación PPP a nuestra nueva pila de red. Agregue soporte para módem de línea telefónica, incluido el encuadre HDLC y la compresión VJC (portar ambos algoritmos es suficiente, pero asegúrese de que la licencia sea compatible con MIT). Implementar la autenticación CHAP. Encuentra y corrige errores.
Entradas: # 812 , # 869 , # 873 , # 922 , # 923 , # 1059 , tal vez: # 1057 , # 1058
Protocolo de transmisión de control de flujo (SCTP)
Implementar y probar SCTP, un protocolo de capa de transporte basado en mensajes similar a TCP y UDP. Debe cumplir con las implementaciones actuales de IP e IPv6 y proporcionar una API de programación similar a la de BSD.
Finalización de IPv6
El marco base para el soporte de IPv6 se implementó como un proyecto Google Summer of Code 2010. Aun así, quedan muchas tareas de limpieza / finalización más pequeñas que se pueden realizar como un proyecto.
Entradas:
# 8293 - BNetworkAddress necesita verificar si hay una conexión IPv6 disponible.
# 7228 - RFC: BNetworkInterfaceAddress necesita almacenar marcas de configuración automática
# 6489 - ifconfig necesita validar la disponibilidad del módulo ipv6 antes de la utilización
# 2632 - Posible redefinición para struct sockaddr_in, relacionada con IPv6
# 8319 - Haiku necesita la detección de direcciones duplicadas de IPv6 durante la configuración ip del alcance del enlace.
# 8317 - Haiku necesita una configuración automática de alcance global de IPv6 (anuncio de enrutador + DHCPv6)
# 11862 - Retrabajo multiprotocolo servidor de red
Ampliación y mejora del backend de la red del Kit de Servicios.
El navegador WebKit y algunas otras aplicaciones de Haiku, como HaikuDepot, usan el Kit de Servicios como un backend de red. Esta es una biblioteca similar a rizo o sopa , pero bien integrada en la API de Haiku para un uso fácil en aplicaciones nativas. Sin embargo, el kit de servicios sigue siendo un trabajo en progreso y se puede mejorar de varias maneras. El trabajo en esta tarea podría incluir:
Reelaborando el kit de servicio para evitar generar un hilo para cada solicitud de red. Se debe permitir que las solicitudes se ejecuten en un hilo existente, o que se agrupen (mediante el uso de select () o poll () para esperar la actividad en sus sockets, y luego enviar eventos a los objetos de BNetworkRequest). Esto eliminaría parte de la sobrecarga de crear una solicitud y resolvería algunos problemas de diseño en la API del Kit de Servicios.
Implementando el soporte de HTTP 1.1, permitiendo la reutilización de la conexión a un servidor HTTP para realizar múltiples solicitudes. Los objetos BHttpRequest se deben volver a trabajar para poder utilizar una conexión HTTP 1.1 existente, y se debe agregar una forma de almacenar las conexiones existentes.
Una capa de almacenamiento en caché para las solicitudes HTTP. Actualmente no hay caché, lo que significa que algunas solicitudes se realizan una y otra vez al mismo servidor. El caché debe mantener el resultado de estas solicitudes en el disco y / o en la memoria, haciendo posible reutilizarlas y cargar las páginas web más rápido.
Soporte completo para proxies HTTP. Si bien actualmente hay soporte limitado, no es posible realizar solicitudes HTTPS a través de un proxy. Esto debe agregarse, así como una interfaz de usuario de todo el sistema para configurar y administrar proxies.
Implementando el soporte FTP. El kit de servicios está diseñado para admitir múltiples protocolos, pero actualmente solo se admiten HTTP y Gopher (así como los protocolos locales de "archivo" y "datos"). El soporte de FTP en el navegador web sería útil.
Interfaz de usuario
Refleting preflet GUI
Varias aplicaciones de preferencia (también conocidas como prefletes) podrían ser rediseñadas. Además, es posible que todavía haya código que aún no use nuestra API de diseño. Este trabajo puede incluir (pero no se limita a):
combinando keymap y teclado
combinando mouse y touchpad
# 6983 Impresora
# 6206 integra las opciones de la barra de desplazamiento en un nuevo preflet de Apariencia
Atajos
Notificaciones
Vista de edición modular
Muchas aplicaciones Haiku están utilizando su propia vista de edición para proporcionar funcionalidades básicas de edición. Todas estas implementaciones funcionan de manera un poco diferente y crean una experiencia de usuario inconsistente. Una solución es proporcionar una vista de editor modular y potente que se pueda usar en varias aplicaciones Haiku.
El diseño de la vista de edición debe ser modular y extensible para facilitar su implementación, por ejemplo, las siguientes funciones:
resaltado de sintaxis
corrector ortográfico
completar código, completar palabra
números de línea, regla, línea de límite de 80 caracteres, hipervínculos
trabajando en un flujo de entrada en lugar de en un archivo de entrada, por ejemplo, para poder abrir archivos de ~ 100Mb sin cargarlos en la memoria de una sola vez.
interfaz a aplicaciones externas, por ejemplo, para saltar de un error del compilador a la línea correspondiente en el código
La reutilización de las bibliotecas de resaltado de sintaxis existentes puede ser posible, siempre que puedan conectarse a una vista Haiku nativa. La licencia MIT sería preferida para la biblioteca externa.
Medios de comunicación
Añadir soporte de subtítulos al Kit de Medios
Si bien nuestro MediaPlayer es compatible con archivos de subtítulos externos, el Media Kit en sí no. El inconveniente más obvio de esto es que no hay soporte para subtítulos (texto o mapa de bits) incrustados en archivos de video dentro de MediaPlayer u otras aplicaciones.
Su trabajo consistiría en diseñar las extensiones API necesarias para que los subtítulos encajen con el resto del Kit de Medios, y agregar soporte nativo para ellos, que luego estará disponible para todas las aplicaciones como parte del marco.
Vea la introducción de BeBook para el Media Kit para familiarizarse con su diseño.
Implementar el selector de entrada / salida en todo el sistema y nivel de aplicación
Cuando se conecta más de una tarjeta de sonido a Haiku, solo puede cambiar la entrada / salida predeterminada en las preferencias de Medios, o volver a conectar los nodos de medios manualmente a través de Cortex a otro dispositivo de entrada / salida. El Kit de medios podría admitir nodos predeterminados por aplicación (ya sea sin configurar (predeterminado del sistema) o configurado para un dispositivo específico), y las preferencias de Medios podrían ofrecer una interfaz de usuario para cambiar esto.
Además, las aplicaciones como MediaPlayer y SoundRecorder también deberían poder cambiar el dispositivo de entrada / salida dentro de la aplicación (lo que sería otra forma de alterar la funcionalidad del Kit de medios descrita).
Esta funcionalidad solo debería estar visible si en realidad hay más de un dispositivo de audio conectado al sistema; Si un dispositivo no está disponible, debería usar automáticamente la salida predeterminada.
Parte de este trabajo sería implementar el almacenamiento no volátil que el Kit de Medios utiliza para cada aplicación que está conectada a él, y la capacidad de detectar la aplicación en el próximo inicio. Este almacenamiento también podría usarse para recordar otras configuraciones de sonido por aplicación en el futuro (o si el tiempo lo permite) como la balanza y el volumen relativo.
Soporte de streaming para Media Kit y aplicaciones
El kit de medios y las aplicaciones relacionadas en Haiku se basan en gran medida en la búsqueda de BMediaFile. Esto hace que sea difícil de usar con fuentes de medios que no se pueden buscar, tales como transmisiones por Internet o DVD. Reproduzca lo que se necesita para que funcionen correctamente.