[londons_explore]

I think a far smaller version of this could be built on top of UEFI functionality...

Ie. use UEFI to read/write the disks. UEFI to send/receive packets. UEFI to draw a splash image onto the screen.

Now, you don't need any network drivers, graphics drivers or disk/controller drivers.

[londons_explore]

I kinda wish Linux would implement support for all the UEFI functionality. It would let you build micro systems which 'just worked' with no drivers.

The downside is that UEFI drivers tend to be barebones and not high performance. But it is a nice fallback to know that you will always at least have something that works.

For example, here is the API for disk access offered by UEFI: https://uefi.org/specs/UEFI/2.10/13_Protocols_Media_Access.h...

[pzmarzly]

This is already possible with kernel patches in https://github.com/osresearch/safeboot-loader . It is extremely cool, but the README there also explains why it's not necessarily a good idea.

[NovemberWhiskey]

I mean, as a proof of concept, that would be neat. As a useful service; not so much with the non-optimization of the UEFI abstraction layer.

[vacuity]

As someone who is completely ignorant about this, what does it mean to use UEFI? I was under the impression that UEFI is just the firmware interface presented at boot time to configure stuff. So is this a way to do complex actions at boot time?