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/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:20 EST