Voy a contarles una situación curiosa que me ocurrió y cómo convertirme en contribuyente de un proyecto reconocido.
No hace mucho, estuve trabajando en una idea: cargar Linux directamente desde UEFI...
La idea no es nueva y hay varios manuales sobre este tema. Uno de ellos se puede ver
Mis antiguos intentos de resolver este problema se convirtieron en algo bastante elaborado . La solución funciona correctamente y la utilizo en parte de mis máquinas domésticas. Esta solución está descrita con un poco más de detalle .
La clave del arranque UEFI es que la partición ESP (EFI System Partition) se combina con el directorio /boot. Es decir, todos los núcleos y las imágenes de arranque (initrd) se colocan en esa misma partición desde la cual UEFI puede ejecutar archivos ejecutables y, en particular, cargar los cargadores del sistema. Sin embargo, el núcleo de Linux ya se compila con la opción UEFISTUB en muchas distribuciones, lo que permite que el núcleo se inicie desde UEFI.
Hay un inconveniente con esta solución: la partición ESP está formateada en FAT32, que no permite crear enlaces duros (que el sistema crea regularmente al actualizar initrd). No hay nada especialmente criminal en esto, pero ver advertencias del sistema al actualizar componentes del núcleo no es muy agradable...
También hay otro camino.
El gestor de arranque UEFI (donde hay que registrar el cargador del sistema operativo) puede cargar no solo cargadores/núcleos de Linux, sino también controladores. Así que se puede cargar el controlador del sistema de archivos donde está su /boot y cargar el núcleo directamente desde allí utilizando UEFI. El controlador, por supuesto, debe colocarse en la partición ESP. Eso es lo que hacen los cargadores como GRUB. Pero la particularidad es que todas las funciones que GRUB utiliza con frecuencia ya están en UEFI. De hecho, en su gestor de arranque. Y si queremos ser un poco más técnicos, el gestor de arranque UEFI incluso tiene más capacidades en algunas áreas.
Parece una solución atractiva, pero hay un "PERO" (mejor dicho, lo había, pero de esto hablaré más tarde). La cuestión es que el sistema de controladores UEFI es bastante sencillo. No hay un concepto como el de montar un sistema de archivos o vincular un controlador a un dispositivo específico. Existe una llamada de sistema con un nombre condicional 'Map' que toma cada controlador uno por uno y trata de vincularlo a todos los dispositivos que le puedan corresponder, más o menos. Y si un controlador puede conectarse a un dispositivo, se crea un mapeo: un registro de vínculo. Así es como debería inicializarse un nuevo controlador al iniciar, en medio de todos los demás. Solo se necesita poner un bit (LOAD_OPTION_FORCE_RECONNECT) en 1 en el registro de arranque del controlador, y UEFI hará este remapeo global después de cargarlo.
Sin embargo, hacer esto no es tan simple. La herramienta estándar efibootmgr (con la que se configura el gestor de arranque UEFI) no sabía (o no sabía) cómo poner este bit. Era necesario hacerlo manualmente mediante un procedimiento bastante complicado y peligroso.
Y una vez más, al intentar hacerlo manualmente, no pude soportarlo y redacté pidiendo a los desarrolladores que añadieran esta funcionalidad.
Pasaron varios días, pero nadie prestó atención a mi solicitud. Por curiosidad, miré el código fuente… hice un fork y pensé a 'manita' cómo agregar esta característica… 'a manita' porque no instalé nada en mi máquina y simplemente edité el código fuente en el navegador.
Con el lenguaje C sé bastante poco, pero esbozé una solución (principalmente copiando y pegando)… luego pensé: aunque seguro tenga un montón de errores (mis intentos anteriores de corregir el código de otros necesitaban al menos diez intentos para compilar) voy a hacer un Pull Request. Así que .
Ahí descubrí que estaba conectado Travis CI para verificar los pull requests. Y me mostró cuidadosamente todos mis errores. Bien, si los errores son conocidos, ¿por qué no corregirlos? Nuevamente, directamente en el navegador, y en mi cuarta tentativa el código se compiló (un logro para mí).
Y así, sin salir del navegador, hice un Pull Request bastante real en una herramienta que se usa prácticamente en todas las distribuciones modernas de Linux.
Me sorprendió el hecho de que, sin saber realmente el idioma, sin configurar nada en mi parte (hay un buen número de bibliotecas necesarias para la compilación), y sin haber ejecutado nunca el compilador, simplemente 'codifiqué' una función completamente funcional y útil en el navegador.
Sin embargo, mi solicitud estuvo pendiente sin respuesta desde el 19 de marzo de 2019, y ya empezaba a olvidarme de ella.
Pero ayer, esta solicitud fue añadida al master.
Entonces, ¿de qué trata mi historia? Trata de que, con las tecnologías modernas, resulta que ya se puede escribir código real en el navegador, sin tener que desplegar herramientas de desarrollo y dependencias localmente.
De hecho, debo admitir que esta es ya mi segunda solicitud de extracción en utilidades conocidas (al menos en círculos reducidos). La vez pasada, mi solicitud de corregir la visualización de algunos campos en la interfaz web de SyncThing resultó en mi corrección de una sola línea en un entorno que no conocía en absoluto.
Solo los usuarios registrados pueden participar en la encuesta. , por favor.
¿Debería seguir escribiendo o no?
sí
no vale la pena
Votaron 294 usuarios. 138 usuarios se abstuvieron.
Fuente: habr.com
