OK, that one I am happy with.
> - does it really make sense to make a device out of it? Might it not be
> equally useful as just a "mtrr" user program that just happens to
> invoce a kernel module (that unloads immediately after having done its
> foul deed).
Doing it that way (i.e. what proform does) is less useful. It's also
slower because the X server would have to fork/exec insmod to load the
module, instead of a simple ioctl(2). Ideally, the X server would
destroy it's region(s) when its VC is switched out, and would create
them again when its VC is switched back. Loading modules every time
would be performance pig.
As for why a /proc interface is more useful:
- it maintains state for multiple regions, so you can:
- support multiple programmes (X server, svgalib) and kernel code
(KGI) creating regions and "destroying" them when no longer needed: a
usage count keeps track of things
- it provides the user/sysadmin with a simple ASCII interface showing
what the current setup is
- being able to destroy regions may be important for some programmes
which don't work properly with write-combining. The ability to
disable/re-enable write-combining quickly may be needed when certain
operations don't work with write-combining, but others (most)
operations work fine and benefit from write-combining.
With multiple heads and multiple programmes accessing the display and
fiddling MTRRs, a /proc interface with state is more robust. Also, I
found that the proform approach was rather clunky.
So, IMO a /proc interface is more robust and more efficient.
Regards,
Richard....