Messages in this thread | | | Date | Wed, 8 Dec 1999 14:29:14 -0700 | From | Richard Gooch <> | Subject | Re: What I suspect |
| |
Linus Torvalds writes: > > > On Wed, 8 Dec 1999, Richard Gooch wrote: > > > > I don't see why the kernel can't map this magic page to the same > > virtual address for each process. I assumed you'd want to do that for > > code anyway. > > So what is your argument with my approach then? > > That's EXACTLY what I've been arguing the whole time. No MAP_INHERIT > anywhere, just a magic mapping that is always present.
Hm. We've definately been talking past each other :-)
I'm suggesting two solutions. A global magic page of kernel data (no code), and CPU-specific code mapped in with MAP_INHERIT. The magic page is placed at a known VA.
Now, in the simple case, MAP_INHERIT will deposit code "somewhere" in the VA space (preferably the same VA for each process), and PIC code is needed to jump to that code.
But, I don't see any obvious reason why mmap(2) can't be called with a specific VA, even if MAP_INHERIT is set. In which case, pick an address, build the tools with that knowledge, and build libc with that knowledge as well. Thus you don't even need PIC code.
I don't know how much it matters to you that we avoid PIC code for various optimisations. Sure, it would be nice, but is it a big deal? Besides, I think we can do that with MAP_INHERIT anyway.
The thing I don't like about a global page which has code is that it's not expandable. And kernel images need to keep copies of various implementations in __init data, which is a problem for embedded systems. You can get around that with CONFIG options, but it's starting to look messy to me.
Regards,
Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca
- 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/
| |