torvalds@transmeta.com said:
> Pulled, but that /proc/mm crap has to go (it wasn't in this patch, or
> I would have rejected it).
Which is exactly why it's not in that patch. I realize that it's a lousy
interface - I'm putting it out there because I don't really have any better
ideas and I'm hoping other people do.
The next iteration of that patch will turn /proc/mm into /dev/mm, but that's
not really a great improvement. It just improves things around the edges a
little.
> What are the semantics the host code wants/needs,
1 - Multiple address spaces per process
2 - Ability to make a child switch between address spaces
3 - Ability to manipulate a child's address space (i.e. mmap, munmap, mprotect
on an address space which is not current->mm)
> and how can we
> implement a sane generic mechanism that doesn't involve opening magic
> files?
Beats me. My first suggestion was to add another file descriptor argument
to mmap et al which would represent the address space to be modified. Alan
didn't like that idea too much.
That still requires getting the descriptor from somewhere. The obvious
alternative to opening a magic file is a system call, new_mm() or something.
BTW, there is some attraction to being able to open /proc/<pid>/mm and getting
a handle on that process' address space. UML doesn't need this, but I bet
there are people who could figure out how to put it to good use.
So, here are the alternatives that I know of. Sane replacements are craved.
Creating a new, empty address space -
open /proc/mm (current UML host patch)
or system call new_mm()
Switch a child from one address to another -
PTRACE_SWITCH_MM (current UML host patch)
Manipulate a child's address space -
write a request struct to a /proc/mm fd (current UML host patch)
or add another fd to the mmap et al calls
Some obvious extensions to this (which UML doesn't need)
switch yourself from one address space to another
open and change another process' existing address space - if we're
going with system calls instead of magic files, then get_mm(pid) would suffice
for the open.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Dec 31 2002 - 22:00:12 EST