(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 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
