efivars

[Greg KH]

On Thu, Sep 23, 2021 at 05:56:43AM -0400, Ruben Safir wrote:
> On Wed, Sep 22, 2021 at 06:07:49PM +0200, Greg KH wrote:
> > If you don't like this, wonderful, use a system based on a different
> > type of bootloader.  But in the end, they end up all having to do the
> > same thing somehow :)
> > 
> > > All I want the boot loader to do is fine the kernel and run it.
> > 
> > Your bootloader also has to do a lot more things (initialize hardware,
> > provide information to the OS as to what hardware is present, do
> > system-level things like suspend/resume, etc.)
> > 
> 
> Why does it need the bootloader to do any of that.  It just needs to
> bring up enough hardware to find the kernel and read it... STDIO, STDOUT
> and the hard drive, assuming it is not a network boot.  The hardware's
> firmware has to initialize so minimal subset of hardware, but that has 
> nothing to do specifically with UEFI.

Define "minimal" please.  What about your RAM?  Your north/south bridge
and the i/o controllers there?  Your processor init sequence?  Find the
boot disk to start with?  How do you tell the bootloader _where_ the
boot disk is?

> Since when does the OS not control all the hardware on the system?

For x86 systems, since i486 days.  Again, remember APM?

> What you seem to be saying is that the UEFI shell is running
> simutanously to the OS, and controls hardware.

No, not at all, the "shell" is not running, but parts of it are running
and are called by the OS to do things.  Sometimes those things wake up
the OS and tell it to do things.

> That is all news to me.
> It doesn't happen in BIOS mode or systems that are still BIOS, dieing
> breed that that is.

Yes, it happened in much worse ways in the "old style BIOS" modes and
systems.  Now it is documented and unified and works much better than
ever before.

Yes, it is more "complex" than before, but you are using a much more
complex system than you used to have as well.

thanks,

greg k-h