Messages in this thread | | | Date | Tue, 15 Jul 2008 17:54:01 -0600 | From | Alex Chiang <> | Subject | Re: [PATCH 00/14] Introduce cpu_enabled_map and friends |
| |
I didn't include linux-ia64 originally. Sorry about that.
Here is the 00/14 cover email describing the patch series:
http://lkml.org/lkml/2008/7/14/468
Here is the 12/14 ia64 specific bit:
http://lkml.org/lkml/2008/7/14/478
Here is the 14/14 patch that Tony is referring to:
http://lkml.org/lkml/2008/7/14/482
* Luck, Tony <tony.luck@intel.com>: > > Patch 14 is the money patch. It demonstrates why we might > > want to go through all these gyrations. Now that ia64 presents > > *all* physically present CPUs in sysfs, even if they have been > > disabled by firmware, we give userspace a way to poke at those > > CPUs. > > There's only the one bit for "disabled by firmware" ... no extra > space for any extra information. How would userspace know that > it was safe to poke at a disabled cpu? Perhaps firmware disabled > it for some very good reason, and poking at it could cause system > instability.
My thought here was that it would be a vendor-specific thing. In patch 14/14 I created:
/sys/devices/system/cpu/cpuN/deconfigure
(although /sys/device/system/cpu/cpuN/enabled would probably be better)
I set up 'deconfigure' to have different implementations based on a DMI, so it is very much an opt-in (especially since it's a Kconfig option).
It would be the responsibility of the vendor to provide something safe to poke at. In the sample implementation I gave, nothing happens to the system until the *next* reboot, so it shouldn't cause the current boot any distress.
A different implementation of deconfigure/enabled could return an error to userspace if an operation was unsafe.
/ac
| |