Well, the thing is, if we ever do want to support it (and I suspect we
do), we should have the infrastructure ready. It shouldn't be too hard to
support SMP suspend in a 2.7.x timeframe, since it from a technology angle
looks like simply hot-plug CPU's. Some of the infrastructure for that
already exists.
But I seriously doubt we want to do CPU hot-plug as a device driver.
Having a hook in place for it in the arch directory will make it easyish
to add once we integrate all the other hotplug code (which is very
unlikely in the 2.6.x timeframe).
> I could probably get away with simply having apm.c invoke the C code
> in suspend.c, which does restore the SYSENTER MSRs. suspend.c itself
> doesn't seem to depend on the SOFTWARE_SUSPEND machinery, but
> suspend_asm.S does.
>
> Does that sound reasonable?
Sounds reasonable to me. In fact, it looks like it really already exists
as the current "restore_processor_state()" thing.
In fact, that one already _does_ call "enable_sep_cpu()", so what's up?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/