Zhang Yanfei <[email protected]> writes: > 于 2013年05月25日 11:01, Eric W. Biederman 写道: >> Zhang Yanfei <[email protected]> writes: >> >>> Hello Eric, >>> >>>> The function copy_oldmem_page also concerns me. I don't have a clue why >>>> we duplicate that function on every architecutre in a slightly different >>>> form. There should be enough abstractions in the kernel to make that >>>> unnecessary. I would be glad to see that function go, and remove the >>>> possibility of confusion that happened on s390. >>> >>> You mean we should have a common copy_oldmem_page for all architectures? And >>> just like vivek said above, for s390, we should put the swap info in the elf >>> headers instead of doing that in copy_oldmem_page. >> >> Exactly. >> >> The user space change in /sbin/kexec should even be backwards compatible >> for s390. So fixing /sbin/kexec should probably come first. >> > > I am kind of not sure about the "backwards compatible for s390" you meant. > > For s390, if we put swap info into the elf header, This will change > /sbin/kexec. > But at this point, copy_oldmem_page is still doing the swap when we try to > read > the pages among [0 - OLDMEM_SIZE] and [OLDMEM_BASE - OLDMEM_BASE + > OLDMEM_SIZE]. > So removing the swap in copy_oldmem_page should be done at the same time. > New kexec with old kernels would fail and old kexec with new kernels would > fail too. > > So could you please explain more about the ""backwards compatible". And please > correct me if I am wrong.
It looks like my misreading of things. I was not expecting the existing copy_oldmem_page to do a complete swap of addresses. I was expecting something like the result obtained by doing a header swap with the ELF headers where part of the address was translated and the rest was simply not mentioned. But from other replies it appears there isn't a problem. Eric -- 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/
