Ben Pfaff <[email protected]> writes:
> On Wed, Dec 07, 2016 at 02:15:12PM -0500, Aaron Conole wrote:
>> Ben Pfaff <[email protected]> writes:
>> > On Wed, Dec 07, 2016 at 01:08:43PM -0500, Aaron Conole wrote:
>> >> Ben Pfaff <[email protected]> writes:
>> >> To accomplish this, I'm going down the following route:
>> >>
>> >> 1. Add formatting option to the lib/table.{c,h}, such that we can
>> >> still express the existing output.
>> >>
>> >> 2. Change ofp-print to use a table for flow dumping, with a default
>> >> format that preserves the current format, and the option of changing
>> >> the format.
>> >
>> > #2 is interesting.
>>
>> I don't currently see how to implement #2, while preserving the existing
>> output, unless I implement #1. Is there a way to accomplish this that
>> I'm missing? If not, is #2 compelling enough to accept #1?
>
> I don't understand how you are going to preserve the default format even
> with #1. I assumed you were going to need to write a separate code path
> to do that.
No - that's my last resort.
> Can you explain your plan?
I was thinking of creating a table which had column headings that were,
example:
actions, in_port, priority, table number, etc.
Then a format string such as:
[priority={priority},][table={tableno},]...
where things in the [] would only be printed if all elements in the row
were filled in, could preserve the original output (without the full
working code set it might be difficult to see what I mean), while also
offering the existing --table=XXX output.
In that sense, we could switch from dynamic string in all of the
ofp-print (and sub-calls) to just filling in column data - then have
pre-set table format strings that can be switched between. That also
means any future manupulation (ex: changing the colors, or something
else) could just be handled the same way existing prints are handled.
-Aaron
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
