Jeff Garzik <[EMAIL PROTECTED]> writes:

> "Eric W. Biederman" wrote:
> > 
> > O.k. I just looked at how the linux kernel is using acpi,
> > in acpitable.c and reskimmed the acpi spec to see what I was
> > missing.
> > 
> > The Linux kernel isn't using true acpi at that point.  All
> > it has is code for the mptables, and it finds the mptable
> > (or a minor variation of thereof via acpi).  But acpi
> > as a side issue does provide a good way to find other
> > tables which is handy.   It looks like it may also provide
> > hooks to point at the more interesting dmi tables.
> > 
> > The stuff isn't strictly acpi but it is very useful.
> 
> How feasible/reasonable would it be to have linuxbios use ACPI as its
> table format?

We could embbed an acpi table in the LinuxBIOS table.  Or provide
a converter.  For now I like the idea of at least having an internal
format we can control and then converting on the fly to what the OS
needs.  

When I checked the core of ACPI had some rather strong PC architecture
assumptions that I wouldn't want to get caught with.  And to use it
fully you have to do the AML thing, which is ugly.

> The ACPI guys seem the listen and respond to feedback, they might even
> consider changes to drivers/acpi for linuxbios, if the changes were
> generally useful.

The ACPI linux developers?  Hopefully we can just be another table
format that gets parsed.
 
> And, slight tangent, the general ia32 OS kernel method for probing
> memory size(s) is via BIOS INT e820 (or is it e802?). 
int 0x15 eax = e820 gives the ranges
int 0x15 eax = e801 gives the top of memory not limited to 64M
int 0x15 ax=88  gives the amount of extended memory.


> Anyway, it
> provides a list of memory ranges, and what type of information that
> memory range contains (useable RAM, ACPI table, etc.).  Providing e820
> info to ia32 OS kernels would be a big step towards providing an easy
> way to serve memory info and ACPI tables to all OS's.

We already provide e820 style information, in the LinuxBIOS table,
which sits just below address 0.  I might relocate it someday with
a pointer but that just seems silly.

So we are pretty flexible, and ultimately the output can be whatever
is sane.

Eric

Reply via email to