Messages in this thread | | | Date | Sun, 13 Jun 1999 00:00:59 -0700 | From | Mark Jefferys <> | Subject | Re: holes for ISA boards... |
| |
On Sun, Jun 13, 1999 at 04:11:54AM -0000, Christer Weinigel wrote: % Mark Jefferys <mjeffery@europa.com> wrote:
% >But this part of the patch looks bad to me anyway; it stops anyone from % >mapping part of the hole to VM, but presumably anything that does this % >knows what it's doing (probably a driver mapping memory straight from an % >ISA card). Or am I missing something? % % The test is the other way around from what you expect. Normally % vremap will return NULL for adresses below the top of memory (since it % probably would be a mistake to allow physical RAM to be mapped by a % driver), my patch excludes the memory hole from that test. % % if (MAP_NR(offset) < MAP_NR(high_memory) % && (offset < memory_hole_start || offset+size > memory_hole_end)) % return NULL;
OK, I was reading the test backwards. Makes sense now.
% >Doesn't look worth saving, as Stephen Early's patch looks more flexible % >(not to mention supporting far more machines). % % Well my patch was a hack to get things working, with minimal changes % to the memory management code in the kernel. It could most probably % be done in a better way.
Stephen's patch supports arbitrary sets of memory ranges, and works with any ACPI-compliant motherboard (in theory). It seems reasonable to my eyes.
But there are two things from your patch that may be worth saving:
a) The fixes in vremap need to be put into ioremap. (Mostly a concept transfer. No code can be saved.)
b) The detection code for the Triton I82437 chipset may be worth transferring, assuming that it doesn't support ACPI.
Mark
- 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/
| |