> However, this doesn't preclude running any other code in userland.
> 
> Just as an example of the things I have in mind, I try to give a short
> description of how threaded code works (at least on CISC architectures):
> 
> The words of the language are implemented with some small code pieces.
> All those pieces end with a return instruction.  The sp points into a list
> of addresses of the words you want to execute.  After executing one word,
> the return instruction at the end of the word's code just pops the address
> of the next word's code and jumps to it.
> 
> In effect, you use the stack pointer as the program counter of the
> interpreted code.

Ok - now signals are asynchronous, so musn't trash *sp.
You also need an OS/CPU where interrupts don't write using the user sp

However by the time anything like that gets near system call I'd guess
(and put a pint or two of beer up as a bet) that it is running some
'native' support code, and has saved sp (aka pc) and restored a real
stack pointer to sp.
> 
> > FWIW another alternative would be to request a page of user memory
> > from the system - must be something in the pmap code for that.
> 
> What you probably have in mind here is mmaping some anonymous page somewhere
> in the user address space for the duration of the system call and using
> that instead of a fixed memory area (hopefully not by some special pmap
> code, which would have to be implemented for every architecture separately,
> but through standard UVM procedures).  Yes, this sounds like a proper
> solution to the problem of requiring some arbitrary amount of user memory
> for the things that started this thread.

yes - that's what I had in mind.
you could probably cache the allocate in the lwp structure to avoid
repeatedly allocating and freeing the page (growing the nunber of pages
if needed).
Maybe a small number of reserved bytes you get you going.
> 
> However, I'd say that implementing a system call emulation by munging the
> parameters into a different structure, copying them out to user memory just
> to copy them in again by the native system call handler, and probably doing
> the same thing for the opposite direction is really a "horrid hack".

The only other alternative would be to have a 'user address is really
address' flag that can be set by the emulation code. And adding cody
to copyin and copyout to that they use kcopy when it is set.
This would add a few instrctions to the normal code paths of every
system call.
(OTOH this would make is relatively easy for kernel code to do user
style activities - eg read config files.)


	David

-- 
David Laight: david@l8s.co.uk