-----Original Message-----
From: Dong, Eddie <eddie.dong@...>
Sent: Tuesday, July 26, 2022 12:30 AM
To: Cao, Minggui <minggui.cao@...>; acrn-dev@...
Subject: RE: [acrn-dev] [PATCH 1/2] hv: shell: improve console to buffer
history cmds

I didn't see the difference of above 2 ranches. Did I miss something?

Also why not directly use memcpy?

[Cao, Minggui] I improve it here for that: it could use to move /
copy chars in the same buffer (could be partly overlap) and it
could start from

right or left.

I have checked the HV's memcpy can't fill this requirement.

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?