lkml.org 
[lkml]   [2000]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] fancy new memory detection, for pre-patch-2.3.48-2


On Sat, 26 Feb 2000, david parsons wrote:
>
> Nathan Zook and I have been working on and off on making the e820 memory
> detection patch work a little better for a while, and we seem to have
> ground to a stop. So what I'd like to do is get the kernel-side of the
> patch (plus some of the reworked linux-side code) into the kernel, so
> that the reports of e820 gumming up on zero-length memory segments or
> memory segments in video memory can be dealt with, and so that a larger
> audience can have it running on their machines to shake out any boundary
> conditions.

I hate all these 16-bit assembly code modifications.

Why do I care whether ds/es changes during the e820 call? And why should
the 16-bit asm code care?

Why not just have the asm code be Simple, Stupid and Straightforward (the
rule of asm: follow the three "S"es). None of this config crap in asm
that is impossible to follow, why not just have the asm code
- save state before the e820 call
- save the result of the e820 call buffer
- save the register state after the e820 call.
- do the old-style calls regardless

Then, the decision on whether we actually _trust_ the results can be done
in plain C code, instad of having this jungle of assembly language.. No
conditionals, no complex decisions on whether to sanity-check the results,
no complexity in assembly code. We can do the real parsing later.

This was my argument against the original e820 patches (and they got
cleaned up, at which point it got applied), and it's my argument against
this new version too. I don't like assembly language, and I like it even
less when it is full of config options.

Oh, and btw - the C code you _do_ have is mis-indented.

Linue


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.347 / U:0.564 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site