From: Dong, Eddie <eddie.dong@...>
Sent: Tuesday, July 26, 2022 10:21 AM
To: Cao, Minggui <minggui.cao@...>; acrn-dev@...
Subject: RE: [acrn-dev] [PATCH 1/2 v2] hv: shell: improve console to buffer
Why we need this kind of difference? I am not convinced/
[Cao, Minggui] there is a rule for history cmds: it is not a loop, if
[Cao, Minggui] it is a ring buffer, if the buffer is not fullUnderstood. But we don't need to check it.
filled and full, the index shall be Handled differently. For
example, if total buffer size 8, now just buffered 4, the index
shall Be just in 3-0;
For key_UP, it can do like:
If ( --p_shell->selected_index < 0 )
p_shell->selected_index += p_shell->total_buffered_cmds;
press up or down key always, it will go up/down to the first or last
command as the end one, so the user will know the history is to end.
1. if the ring buffer not full, up key will go until 0 index, then
it will not change any more.
2. if the ring buffer is full, up key will also go to an end index
too and will not change any more then.
[Cao, Minggui] OK, let me explain in detailed, Let me give two examples:
1. if ring buffer full is 8, now buffered index: 0, 1, 2, 3, total_buffered_cmds is 4; if up key on and on, it will go as:
3-->2-->1-->0, and then if up key again, it keeps as 0, and not change again.
2. if ring buffer is full, and buffered index order is: 4, 5, 6, 7, 0, 1, 2 ,3, and start from 3, for up keys, it will go as:
3->2->1->0->7->6->5->4, and then keeps as 4, not change again for more up keys.
When I check bash, found it is not a loop, I think the reason is user-friendly: user can know when it is the end
of the history buffered cmds.
As the two cases, I have not found how to unify the code; if adopt the above code, it is a loop, it is fine, but not
user-friendly, the user could search more time.
I updated this patch to V3, and sent it out, combine "input_line" and
"buffered_cmds" as "buffered_line", and simplify some logic as your
Could you have a review?