Messages in this thread | | | Date | Sat, 17 Jul 1999 00:38:34 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: New kernel/resource.c |
| |
On Sat, 17 Jul 1999, Rogier Wolff wrote: > > > > No, ioremap() (which is what I assume you're talking about, rather than > > vmalloc()) > > 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.
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/
| |