🥇The future is already here or we code right in the browser

I will share a funny situation that happened to me, and how to become a contributor to a well-known project.

Not long ago, I was working on an idea: loading Linux directly from UEFI…
This idea is not new, and there are several manuals on this topic. One of them can be viewed here

My long attempts to solve this issue turned into a well-structured the decision. The solution is quite functional, and I use it on some of my home machines. A bit more detail about this solution is described here.

The essence of UEFI-Boot is that the ESP (EFI System Partition) combines with the /boot directory. That is, all kernels and initial ramdisk images (initrd) are placed in the partition from which UEFI can launch executable files, including the system bootloaders. But the Linux kernel itself is now being compiled with the UEFISTUB option in many distributions, allowing the kernel to be launched from UEFI.

There is one unpleasant aspect to this solution — the ESP partition is formatted in FAT32, which does not allow the creation of hard links (which the system regularly creates when updating initrd). While there’s nothing particularly criminal about this, seeing system warnings when updating kernel components is not exactly pleasant…

There is another way.

The UEFI boot manager (the one where the OS bootloader needs to be specified) is capable of loading not only Linux bootloaders/kernels but also drivers. So it is possible to load a driver for the filesystem where your /boot is located and load the kernel directly from there using UEFI. The driver, of course, needs to be placed in the ESP partition. This is roughly what bootloaders like GRUB do. However, the twist is that many frequently used functions of GRUB are already present in UEFI. To be more precise, the UEFI boot manager actually has even more capabilities in certain matters.

It seems like a beautiful solution, but there is one "BUT" (or rather, there was, but more on that later). The thing is that the UEFI driver system is quite straightforward. There is no concept of mounting a file system or linking a driver to a specific device. There is a system call with a conditional name Map (in English) that takes each driver in turn and tries to link it to all suitable devices, no matter how well or poorly they fit. If the driver can connect to a device, a mapping is created — a linking record. This is how the newly loaded driver should initialize itself among all the others. All it takes is to set one bit (LOAD_OPTION_FORCE_RECONNECT) in the driver's boot entry to 1, and UEFI will perform that global remap after loading it.

However, doing this is not that simple. The standard utility efibootmgr (which is used to configure the UEFI boot manager) cannot (more precisely, could not) set this bit. One had to do it manually through a rather complicated and dangerous procedure.

So once again, after trying to do this manually, I couldn’t take it anymore and created an issue on GitHub with a request for the developers to add this feature.

A few days passed, but my request went unnoticed. Out of curiosity, I looked at the source code... I forked it and figured out, "on the fly," how to add this feature... "on the fly" because I didn’t install anything and was editing the source code directly in the browser.

I know C (programming language) very superficially, but I sketched out a rough solution (mostly copy-pasting)... then it occurred to me — even if I most likely had a bunch of errors (my previous attempts to edit someone else's C code had succeeded on the tenth try) I might as well submit a Pull Request. So I submitted it..

Turns out they had Travis CI attached to verify pull requests. It diligently pointed out all my mistakes. Well, since the mistakes were known, why not fix them: right in the browser again, and on the fourth attempt, the code compiled (an achievement for me).

And so, without leaving the browser, I created a fully viable Pull Request for the utility that's used in practically all modern Linux distributions.

I was surprised to find that I, not knowing the language well and without configuring anything (there's quite a substantial set of libraries needed for building), and never even running the compiler, managed to "code" a fully functional and useful feature right in the browser.

However, my request had been hanging without a response since March 19, 2019, and I was starting to forget about it.

But yesterday, this request was added to the master branch.

So what is my story about? It's about how, within the framework of modern technologies, it has turned out that real code can already be written in the browser without setting up any local development tools or dependencies.

Moreover, I must admit, this is my second pull request to well-known (at least in narrow circles) utilities. The last time my request to fix the display of some fields in the SyncThing web interface resulted in literally a one-line correction in an environment I didn't know at all.

Only registered users can participate in the survey. Please log in, please.