Messages in this thread | | | From | david parsons <> | Subject | Re: [PATCH] fancy new memory detection, for pre-patch-2.3.48-2 | Date | Mon, 28 Feb 2000 13:02:08 -0800 (PST) |
| |
Jeff Garzik wrote: > > david parsons wrote: [paranoid memory detection]
> > As a vendor, I don't want to do it because it's like constantly > > checking to make sure that 2+2 = 4, but I can also see why a > > motherboard or processor vendor might want to pull open all the > > stops while validating a bios. > > Well, it is cheap since it can easily be __init code, so please consider > doing ALL checks, paranoid or not.
For Mastodon, no, I probably won't[1]; but I certainly would prefer that the assembly-side of the patch have the OPTION to do the checks. __init doesn't really apply to the assembly side[2], and the thing that's important to me is not whether the code is reclaimed, but how much room the kernel image takes up on disk because there's only so much you can fit on a 1.44mb install floppy.
But this depends on what Linus wants; I can defer most of the paranoia checks to the kernel-side (Sundays patch does just this by moving start+size >64 bits and len < 20 into kernel/setup.c) for free. Passing up es:di to the kernel-side takes space out of the 1kb buffer I've set aside for e820 results, which eats into the comfortably large 32 element + 240 byte slop area that I've got set up now.
> IMHO MandrakeSoft would always compile in the paranoid checks, simply > because you never know what sort of filth like buggy BIOS is out > there...
I don't think the commercial bioses would have any problems because not being able to run Linux or Windows on systems with those bioses would result in no sales. The various freeware bios efforts, on the other hand, scare me, because there is no good negative feedback against maliciously broken features; I CAN see a freeware bios deciding to ``helpfully'' break both the e820 definition and ACPI by moving es:di to point at the next element, and in this case I would much rather have the Linux kernel simply fail catastrophically instead of tolerating the broken feature [3]
____ david parsons \bi/ It works fine under 2.0.28+logo; no 1.2.13 patch yet. \/
[1: The current e820 code is running on a lot of machines, and I've yet to see any reports where the assembly-side code fails outside of one report where e820 only returned one record describing the low memory area.]
[2: the assembly-side is already stepped all over by the kernel.]
[3: if somebody breaks e820 in their freeware bios, they will most likely test it on one of their machines before dumping it on their ftp site. Having their machine lock up and die would be a pretty compelling reason to not ship the offending code.]
- 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/
| |