Re: [PATCH 1/2] hv: shell: improve console to buffer history cmds


Eddie Dong
 

1: This is not char copy, but memory copy.
2: The reason memcpy today doesn’t support this feature is
because it only work with DF=0 (REP MOVSB). We can easily
extend to support
DF=1.
[Cao, Minggui] sorry, I mixed the copy and move; it shall be
like
memmove.
Just checked the memory.c code in HV.

Is it OK as follows?
memcpy_erms --> memmove_erms (void *d, const void *s, size_t
slen, bool
df_flag) as a public API?
The caller side clearly know the copy to be from head to tail
address or from tail to head address.
How about to define another API like memcpy_tail_to_head or
memcpy_rev ?

The caller side can choose normal memcpy or tail_to_head copy API.
[Cao, Minggui] normally memcpy (also in HV), it will not handle the
src and
dst overlap case,
but memmove can handle that. I shall change copy_chars to
move_chars (or
move_bytes) to use in shell input to delete/insert locally in my 2nd patch.
[acrn-dev] [PATCH 2/2 v2] hv: shell: improve console to modify
input easier

Then I thought no other will use it, I just did a simple one. If
need to add new API, it is better to add new: memmove /
memmove_from_tail two APIs to memory.c Is it OK?

I am not sure if this is MOVE or not. MOVE means using a temporary
buffer to hold the source bytes?

To me, memcpy is fine.
[Cao, Minggui] for current memcpy in HV/memory.c

if ((d != NULL) && (s != NULL) && (dmax >= slen) && ((d > (s + slen)) || (s > (d +
dmax)))) {
===> it checks the range of s (src) and d (dest), if overlap, it will not
handle.
Oh, I am talking about memcpy_erms & memcpy_tail_to_head/memcpy_rev

BTW, I forgot where does ERM come from.


For this patch, it is OK, I can improve this patch. I re-write one (copy_chars /
move chars) is for 2nd patch, but is for delete/insert a char in the input_line
array, for example:
if current input-line is: abcdefg
1. if cursor move to d, and delete it, "efg" need move one byte forward to
display.
2. if cursor move to d, and insert a "h", "defg" need move one byte backward
to display.

Both have some overlay address space. if use copy to a temp and copy back
again, it can work. I wanted to make it simple to operate.
To write one local function to handle overlap space and can be from head or
from tail to start.

I searched some info: https://stackoverflow.com/questions/1201319/what-is-
the-difference-between-memmove-and-memcpy


Join {acrn-dev@lists.projectacrn.org to automatically receive all group messages.