A 16MB top window seems to be a generic window, most APIC/IOAPIC are mapped at 4GB - 20MB IIRC
My dream is to have a chip specific driver (map driver in MTD terms) which knows the window size the BIOS hardware decoder supports, including the optional enable bits.
The chip driver also interacts with Linux /dev/iomem to reflect the current setting of the optional enables.
It should also update the below 1MB (and maybe below 16MB) aliases in /proc/iomem, according to their actual status in the hardware. For example, the K8 northbridge fixed MTRRs could be disabled, rendering any aliasing of the southbridge or LPC/FWH parts moot (from the processor's perspective at least)
There is a similar (lack of) infrastructure issue with lmsensors ATM, might be interesting to watch progress there
Regards,
Jeremy
On Wed, 2007-06-06 at 18:00 +0200, Peter Stuge wrote:
On Wed, Jun 06, 2007 at 10:47:59PM +0700, Darmawan Salihun wrote:
I know, it's not a good example of software engineering practice. Nonetheless, I want to discuss, on which API that I should be removing from user mode application accesses and which one to retain.
I couldn't make out much of it.
Again, I think the evolution goes like this:
- Kernel driver allowing unrestricted reads and writes to top 16MB.