Nigel Cunningham wrote:
* Driver suspend and resume calls should only handle cpu0, and should not
touch other processors. The same semantics regarding hardware state and
values of variables apply here.
Isn't the trouble that in this case, the devices themselves are the
CPUs, and so the CPUs themselves need to operate on their own state?
Or perhaps, to look at it another way, suspend/resume is just a special
case of:
1. unplug cpus 1-N
2. [something]
3. re-plug cpus 1-N
where [something] in this case is "suspend cpu0".
But the problem is that there's nothing which keeps track of whether the
re-plugged cpus 1-N are the "same" as the unplugged 1-N, and so nothing
can apply the same per-cpu settings to them. In the suspend/resume case
they clearly are, but in the general remove/add case, do you really want
the new CPU to get the same state as the old one just because it ends up
with the same logical CPU number? Perhaps, but what if it doesn't even
have the same capabilities? (Do we support heterogeneous CPUs anyway?)
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
