Yes, so far I've only been talking about physical addressing resources.
> Now, virtual adressing space
> is also a scarce resource.
Agreed.
In fact, the virtual address resource was really what drove me to actually
re-write the resource management. I got patches from sparc people that
kind of mis-used (or depending on how you think of it it could be thought
of as "extending in architecture-specific areas") the old resource code.
They did that exactly because they wanted to keep track of their virtual
memory allocations (which they used for ioremap's - so in this case IO
_was_ actually a secondary concern).
> 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. (*)
Sure.
I don't see all that strong a need for it, but the above is certainly not
wrong, and it _could_ be useful. Do you have any real application in mind,
or do you just want to visualize the current vmallocs in /proc?
So yes, a resource tree like you propose definitely makes sense. I just
don't want to implement (or accept patches) purely on "makes sense": I
really would like to see a real use of it too. Convince me.
(Right now there is already the afore-mentioned sparc-specific use for it,
but that can be considered to be a "private" resource, and not something
that the rest of the kernel ever cares about. Your suggestion would
basically make it a "public" resource, and then I want something else than
just a single architectures internal implementation as a argument).
Linus
-
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/