Re: PROPOSAL: Split uiomove into uiopeek, uioskip

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> - uiopeek leaves uio itself untouched ([...]).
> Hmâ?? Iâ??m having second thoughts about uiopeek(), as well.  It implies a d$

That is a good point.  But would it be a problem to have uiopeek
(works only to move from uio to buffer) and uiopoke (the other way)?

I've never liked the way uiomove can move data one direction or the
other depending on how the uio is set up.  (I'd rather have uioread and
uiowrite except that I'd be constantly trying to remember whether
uioread reads from the uio or moves data in the direction a read()
operation does.)  Maybe uioget and uioput?

Is there any significant amount of code that calls uiomove without
knowing which direction the bits are moving?

As for uiocopy versus uiomove, those are similar enough to memcpy and
memmove that the implication feels to me more like "buffers can
overlap" (for all that that is a highly unlikely use case) or some
such.

Finding good names is a mess.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B