efivars

Greg KH greg at kroah.com
Thu Sep 23 05:39:05 EDT 2021


On Thu, Sep 23, 2021 at 05:17:41AM -0400, Ruben Safir wrote:
> On Thu, Sep 23, 2021 at 09:13:02AM +0200, Bjørn Mork wrote:
> > Ruben Safir <ruben at mrbrklyn.com> writes:
> > 
> > > OS's shouldn't need anything from a boot loader.
> > 
> > Why do you need a bootloader then?
> 
> To boot and that is it.  It is a hardware specific ibinary boot chain that
> finds the kernal on the hard drive and says - load that and run.
> 
> After that, it should serve no purpose.

That is not how modern hardware works, sorry.

If you wish to revisit this, please talk to the hardware designers.

> > I'd suggest playing with embedded devices for a while. Their boot chain
> > is usually much simpler than on PC hardware. There you can really get a
> > feeling of how easy and decoupled stuff could have been. Load a kernel
> > directly to some location in memory and just jump there.
> > 
> 
> That is pretty much all you want.  Firmware creep has gotten so 
> unecesserily complex that UEFI has a virtual machine running in it.

You mean ACPI?  :)

You do remember APM, right?

> I don't need or want it to play a multiplayer networked version of 
> freecell.  I just need it to find the kernel and load it.

You also need to know how to stop the machine, change power levels,
detect some hardware changes, and so on.

> > Then try to expand a bit by reading the kernel from some specific flash
> > device, or even network.  
> 
> Hardware interupts work to announce hardware on the bus.  The devices 
> announce themselves on the system bus.

What exactly do you mean by "system bus"?

> > Or add a file system to
> > the flash.  Etc.  Maybe you even want some way to configure the
> > bootloader from the OS?
> > 
> 
> This wasn't invented with UEFI.  
> 
> > Add all the features you take for granted on PC hardware.
> > 
> > I think you will find that the OS has to be aware of some of the stuff
> > the bootloader does.  And that many of the features depend on the OS
> > communicating with the bootloader somehow.  
> 
> Why?  The Kernel interacts with the hardware independently.  
> The devices each have their own firmware and process data
> according to an API and the Kernel either natively, or through loaded
> modules, processes data from the devices.  There is nothing here for a
> boot loader to do.  It ran its bit on the stack and it should be gone.
> 
> If you run a system in BIOS mode or even with just a BIOS, the Kernal 
> can still do everything, including SATA and Thunderbolt, Firewire,
> PCI-Express, SATA etc.
> 
> What can it do with UEFI that it can not do with BIOS?

What do you think that BIOS is?  It's the same thing that UEFI is, just
that UEFI is the "newer version and standard of BIOS" that solved many
many things that were wrong with the BIOS interface and specification.

Again, remember APM?

thanks,

greg k-h



More information about the Kernelnewbies mailing list