RE: Output ACPI info via sysfs

[Peter Jones <pjones@redhat.com>]

(sorry for breaking threading, I'm not on the list and this was
forwarded to me)

> >Currently, after booting a system there is no way to tell what 
> >hardware 
> >is currently in the system.  The current output from sysfs only 
> >indicates what knowledge the kernel has of the system (ie, is 
> >limited by 
> >NR_CPUS, etc.).  However, during ACPI initialization a lot of data is 
> >output to the console about the precise number of CPUs, lapics, etc.
> 
> Can you give an example of a person or program that can not
> access a specific piece of information that they need?

Anaconda can't determine the number of CPUs or sockets actually present
(in use or not, enabled or disabled) in a system, which we need to do in
order to determine what kernel we should install.

On x86_64 in RHEL, installation uses the default kernel, which is
compiled with support for 16 CPUs.  We can't change that because
changing CONFIG_NR_CPUS changes the module ABI, and breaks modules built
by our ISVs.  But on systems with more CPUs than that, our users are ok
with us breaking that ABI to use more CPUs, as long as it does not
effect systems with 16 or fewer processors.  So we need to probe the
number of processors and install the appropriate kernel.

I've got code to read the ACPI tables from userland right now, but it
isn't terribly reliable.  Some systems lock up if you read the tables
while X is running, and some systems sometimes give erroneous data.  In
both cases, it seems the earlier you read the tables the better, and of
course the kernel reads them while it's still only got 1 CPU running,
which is the best possible case.  The kernel hasn't triggered any of the
failures we've seen, and since it already has to read the tables, this
would be the best place for userland to get that data.

-- 
  Peter