On 5/26/06, Eric W. Biederman <[email protected]> wrote:
"Magnus Damm" <[email protected]> writes:
>
> Also, I feel that my approach with a valid idt and gdt is more robust.
One of my biggest concerns with the current code is that it is not
sufficiently robust, in the kdump case. So I am all in favor things
that improve that situation. At the same time just moving code from C
to assembly doesn't make it more robust, especially when the comments
explaining what the code does don't come along.
I agree that just moving the code does not help. But my code actually
loads a new set of gdts and idts and I'm hoping that it will improve
the robustness.
Regarding more comments I totally agree with you.
>> The big problem was you did several things with a single patch,
>> and that made the review much more difficult than it had to be.
>>
>> Having to check if you correctly modified the page tables, while also
>> having to check for segmentation, and the interrupt descriptor
>> transformations was distracting.
>
> Let me know which parts you think are good and we will implement and
> review them bit by bit instead then.
Skip the infrastructure changes, and the rest looks like real
possibilities.
But I need to store my page tables somewhere, and there is no good
place to store them now. With good reasoning I can be convinced that
storing things on the control page is a good thing, and I'd like to
agree on something, but without good reasoning I will continue to
think that the control page solution is overly complex.
Thanks,
/ magnus
-
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]
