Messages in this thread | | | Date | Sat, 26 Feb 2000 20:02:14 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [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/
| |