>> How evil is to do uiomove() to the reader's uio from within the
>> writer's process context?
> You mean besides that it would copyout() into the writer's address
> space?

Why would it do that?  I can see some possible reasons:

- Maybe the uio doesn't know what address space it's for.

- Maybe we can't fault in pages in a non-current address space.

- Maybe we can't convert virtual->physical addresses for a non-current
   address space (which would make it impossible to access a
   non-current space's memory even if it were faulted in).

The first does not seem to be true; a uio contains a proc pointer, from
which we can find the address space.

As for the other two, if they're true, it seems to me they should,
ideally, be fixed.  (Of course, this is coming from someone who has
never grubbed around in UVM and who specifically isn't volunteering to
do the work. :)

But given the converses of those three, I can't see any reason uiomove
couldn't move to non-current address spaces.

Of course, whether it's worth doing is a completely separate question.
Is saving the copy worth the extra kernel code?  (Note that it doesn't
really save a context switch, since the recipient can't use the data
anyway until it runs.  If the buffer being sent is bigger than the
pipe's internal buffering capacity, though, it means that a big write
can satisfy a big read - or conversely - in one go, instead of chopping
it up into internal-buffer-sized pieces.)

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B