ok, how about splitting smp_scan_config() up into two pieces,
smp_find_config() and smp_get_config():
- smp_find_config() finds the config (the mpf), but does not do a
smp_get_mpf() which dereferences the (potentially high-memory)
pointer, only does a reserve_bootmem() on it.
- paging_init() runs [which will not allocate into the mptable
because we have reserved that 4k area]
- smp_get_config() gets called, which now sees all the RAM. (this is
already present now internally, it's called smp_get_mpf())
in this context smp_find_config() is just part of the 'RAM configuration'
(and e820 interpretation) process - some special reserved system areas
have to be reserved additionally to the e820 map. In fact, if BIOSes were
designed cleanly (and pigs could fly), then the SMP configuration area
would be part of the e820 area. (eg my mpf is at 01009120 which is marked
as 'usable' by the e820 map.) All these special cases would be handled in
a single place.
this splitup should solve all these problems - any objections?
Ingo
-
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:13 EST