Re: ACPI vs DT at runtime

[Mark Rutland <mark.rutland@arm.com>]

Hi,

> > > That
> > > sounds like an arcane board file equivalent, and is counter to the
> > > entire reason for using UEFI and ACPI -- having a well-defined
> > > (excluding particular driver bindings, and I'm not arguing well-defined
> > > means nice) stable standard that allows the kernel to boot on an
> > > arbitrary platform without requiring arbitrary platform-specific code
> > > everywhere in the boot path.
> > >
> > > It might not be pretty, and it will certainly require a lot of work, but
> > > I'd prefer it at least for a semblance of uniformity.
> >
> > That is a red herring -- that booting standard has _nothing_ to do with
> > ACPI. Once you've got a standard that is well-defined enough like that,
> > you no longer need the runtime portions of ACPI to deal with it. You
> > can just hardcode it. You need a way to probe _which_ type of standard
> > is used, but from there on out you can assume that things are the same
> > way.
> 
> The UEFI spec pulls in portions of ACPI. I do not know the full extent
> of the interaction between the two, but I know that they are not
> completely decoupled. As you have pointed out we are not experienced
> with ACPI or UEFI, so I don't think we can make statements that one is
> perfectly fine without the other.

Given Leif's comments it seems that they are decoupled sufficiently to
be considered separately.

Apologies for adding to the confusion here.

Mark.