Background
==========
This `seqnum` (sequence number) feature is currently unused. It was
designed so that the session daemon could tell the tracer the order in
which the bytecode should be run.
Issue
=====
The current implementation of the session daemon doesn't use this
feature so there is only ever a single bytecode to execute per callsite.
During work on an upcoming feature uses this `seqnum` became useful and
it was realized that the current bytecode linking code would reverse the
order in which the bytecode were executed when all bytecodes have the
same `seqnum` value.
This is due to the fact that the `cds_list_for_each_entry_reverse` loops
until it finds a `seqnum` smaller than the new one.
So if all bytecodes have the same `seqnum`, the new bytecode will be
added at the beginning of the list.
This is not technically a problem since it's the session daemon's job to
set the sequence number if it wants a particular ordering. Even
considering that, we found it counterintuitive that new bytecodes are
added at the beginning of the list in those cases.
Solution
========
This commit makes it so that on equality, the insertion is done after
the existing bytecodes.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I784887e3e6085f9344a2bb429d4f0d30586ebc57
/*
* Insert at specified priority (seqnum) in increasing
- * order.
+ * order. If there already is a bytecode of the same priority,
+ * insert the new bytecode right after it.
*/
list_for_each_entry_reverse(runtime,
&event->bytecode_runtime_head, node) {
- if (runtime->bc->bc.seqnum < bc->bc.seqnum) {
+ if (runtime->bc->bc.seqnum <= bc->bc.seqnum) {
/* insert here */
insert_loc = &runtime->node;
goto add_within;