Yeah, OK. My first reaction was to leave it in user space, but since
this facility would be handy for the FBdev drivers as well, I guess it
needs to go into kernel space. Either the individual FBdev drivers do
it, or the MTRR driver does it once. The latter is probably better.
I didn't like the "virtual" MTRRs approach: it's getting really
complicated and starts hiding the details too much, IMO. I'd rather
implement a function that applied the necessary heuristics and created
two MTRRs if needed. So now you have <mtrr_add>, which is the "dumb"
interface, and add the following "smart" interface.
int mtrr_smart_add (unsigned long base, unsigned long size, unsigned int type,
char increment, int *registers, int max_registers)
/* [SUMMARY] Setup a memory region, using multiple MTRRs as required.
<base> The starting (base) address of the region.
<size> The size (in bytes) of the region.
<type> The type of the new region.
<increment> If true and the region already exists, the usage count will be
incremented.
<registers> The MTRR registers used are written here.
<max_registers> The size of the <<registers>> array.
[RETURNS] The number of MTRR registers used on success, else a negative
number indicating the error code.
[NOTE] This routine uses a spinlock.
*/
This even lets drivers keep track of which MTRRs they should release,
if required.
What do people think of this interface? If you're happy, I'll add it
once Linus applies the MTRR patch I recently sent him (adding Cyrix
and AMD support).
Regards,
Richard....
-
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/