No, I was talking about vmalloc. Thinking about it some more, I think
I was confusing virtual and physical adressing space. You're only
talking about the physical adressing space. Now, virtual adressing space
is also a scarce resource.
So, would it make sense to also put the virtual adressing space in a
resource tree? That's where my example belongs.
Kernel virtual adressing space:
0x00000000 - 0xc0000000 Current user process.
0xc0000000 - 0xc00a0000 main memory, below 640k
0xc00a0000 - 0xc0100000 ISA io memory.
0xc0100000 - 0xc4000000 main memory, above 1Mb (*)
0xc4800000 - 0xc8800000 available for ioremap and vmalloc. (*)
This picture would change if you configure for 2G RAM.
If you're saying that ioremap doesn't currently have a "caller-name"
argument, I agree. But with a few macro tricks, it is easy to solve
this in a source-level compatible way.
#define ioremap(p,l) nioremap(__FILE__, (p), (l))
(n for new or named- )
nioremap would then allocate the region from all the appropriate
resource (sub-)trees.
> should not actually grab the region. One reason for that is
> that ioremap() doesn't even know who it grabs it for, another reason is
> that it's actually not illegal to have multiple mappings to the same
> object.
Ok, you're talking about the "physical" end of the mapping. I was
thinking about the virtual end of the mapping.
> Note that "real memory" is actually "io memory" when seen by any PCI bus
> master device. So "real" is in the eyes of the beholder ;)
Very true ;)
Roger.
(*) Numbers valid for a 64Mb machine.
-- ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* ------ Microsoft SELLS you Windows, Linux GIVES you the whole house ------
- 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/