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: > > 1. Kernel driver allowing unrestricted reads and writes to top 16MB. -- linuxbios mailing list [email protected] http://www.linuxbios.org/mailman/listinfo/linuxbios
