On Sun, Feb 7, 2016 at 12:08 AM, Liran Schour <lir...@il.ibm.com> wrote:
> Andy Zhou <az...@ovn.org> wrote on 04/02/2016 11:54:06 PM:
>
> > On Sun, Jan 31, 2016 at 11:03 PM, Liran Schour <lir...@il.ibm.com>
> wrote:
> > Columns indexing is different in ovsdb_row then in ovsdb_monitor_row.
> > We need mapping between the 2 for condition evaluation.
> >
> > signed-off-by: Liran Schour <lir...@il.ibm.com>
> >
> > It may be simpler to and more efficient to have ovsdb_clause to
> > have pointer to ovsdb_monitor_column* than
> > to ovsdb_column directly. We can add a field in
> > ovsdb_monitor_column to store the index for accessing row data.
> >
> > struct ovsdb_caluse {
> > enum ovsdb_function function;
> > const struct ovsdb_monitor_column *column;
> > struct ovsdb_datum arg
> > };
> >
> > If this approach works, then we don't need to maintain the index map.
> >
>
> Ovsdb_clause and ovsdb_condition are being used originally to evaluate
> conditions on ovsdb_row. Because of that ovsdb_clause do needs the field
> ovsdb_column.
> I agree that the index map array does not looks too good but the option to
> overcome it as I see it is to duplicate the code in condition.c for
> ovsdb_monitor_row that will have ovsdb_monitor_clause with
> ovsdb_monitor_column field. What do you think?
>
>
Yes, I am concerned with idea of using index map array to bridge API gaps.
How about the following:
struct ovsdb_clause {
enum ovsdb_function function;
const struct ovsdb_column * column;
unsigned int index; /* column Index into ovsdb_datum for
evaluation.*/
struct ovsdb_datum arg;
}
Without monitor_cond, the new 'index' will be the same column->index.
monitor_cond
can maintain the 'index' field with the same logic as index map. The
condition API can
mostly be reused, No?
> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
