On Thu, May 07, 2026 at 09:09:23AM -0700, Stephen Hemminger wrote: > On Thu, 7 May 2026 09:10:48 +0100 > Bruce Richardson <[email protected]> wrote: > > > > 1. API shape. pcap_compile-style (one string -> opaque object -> > > > arrays) versus the three-call attr/pattern/actions form > > > Sismis's v12 exposes. What does your application actually > > > want? > > > > > > > For this, I wonder if we also could do with a second API for the creation > > which takes a list of tokens rather than just a single string. Thinking > > about integration with testpmd, or with apps which already have some > > commandline interface which produces a list of tokens, having to re-stitch > > the tokens together into one string seems awkward. > > > > Also, have you already investigated how this might be integrated into > > testpmd? Do we have the capability to pass multi-token strings via cmdline? > > Lex pass does tokenizing in a way that is different than simple string split. > Could have a wrapper that takes list of tokens and quotes them back to > a string. > > For testpmd integration. > - the new compiler may intentionally diverge from existing adhoc > parsing. The AI code generation already flagged a couple of these > and put note in documentation. > > - testpmd (and probably cmdline) will need ability to not pass unparsed > string, may need new cmdline type for "rest of line as string" >
Checking with Claude, it seems it's there already: Multi-string (TOKEN_STRING_MULTI) — reads until cmdline_isendofcommand(), which stops only at \n, \r, \0, or #. This captures the entire remainder of the line including spaces. > - AI proposed new syntax: > flow compile <port> "quote rule" I tend to prefer explicit pre-field names in the syntax as a general rule as it makes it clearer what the numeric values in the command are. So I suggest e.g.: "flow_compile port <N> rule: ...." In the absense of quoting, I think having a ":" at the end of rule helps to separate the testpmd syntax from the rule syntax. /Bruce
