DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: "Gaëtan Rivet" <gaetan.rivet@6wind.com>
Cc: Yuanhan Liu <yliu@fridaylinux.org>, dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] doc: document the new devargs syntax
Date: Wed, 17 Jan 2018 10:43:23 +0100	[thread overview]
Message-ID: <3880793.9nSlzmWI4v@xps> (raw)
In-Reply-To: <20180117093749.upv2k6ew5tbvwdsp@bidouze.vm.6wind.com>

17/01/2018 10:37, Gaëtan Rivet:
> Hi Thomas,
> 
> On Wed, Jan 17, 2018 at 01:03:50AM +0100, Thomas Monjalon wrote:
> > 17/01/2018 00:46, Gaëtan Rivet:
> > > On Wed, Jan 17, 2018 at 12:22:43AM +0100, Thomas Monjalon wrote:
> > > > 17/01/2018 00:19, Gaëtan Rivet:
> > > > > It might be a nitpick, but the driver specific properties might not
> > > > > follow the key/value pair syntax. At least for the fail-safe, a custom
> > > > > parsing needs to happen. I think vdev in general will need flexibility.
> > > > 
> > > > What is more flexible than key/value?
> > > 
> > > fail-safe does not need something more flexible, but different.
> > > It needs to define substrings describing whole devices, thus substrings
> > > following the aforementioned syntax.
> > > 
> > > I choose to use ( and ) as markers of beginning and end of the "special
> > > sub-device part that we need to skip for the moment". In the end, I need
> > > a way to mark the beginning and the end of a parameter. Without this,
> > > the next parameter would be considered as the parameter of the
> > > sub-device, not of the fail-safe.
> > > 
> > > = separated key/value pair does not allow for this (or with very
> > > convoluted additional rules to the syntax).
> > 
> > OK, I agree we need beginning and end markers.
> > I wonder whether we should consider devargs as a specific case of value.
> 
> Not sure I follow: you would want to consider a different syntax whether
> we are defining or identifying a device?
> 
> This seems dangerous to me, a single unifying syntax should be used. But
> I probably misunderstood.

No, I'm just saying that it is a more generic problem:
values can contain some characters used in this syntax.
So yes, we need to protect them with parens (or braces).

> > Maybe we just want to allow using marker characters inside values.
> 
> That would be nice. That, or allow drivers to use arbitrary parameters,
> by freeing the last field (past the "driver" token of the last
> category).
> 
> Do you have a justification for restricting drivers parameters? Why
> couldn't this only be structured by commas (or any separators), and otherwise
> left to the drivers to do as they see fit?

User experience.
I don't think key/value is restricting.

> > So we can use parens or quotes to optionnaly protect the values.
> > But as the shell developers learned, parens are better than quotes in
> > the long term because it allows nested expressions.
> 
> This was the initial reason for using parens in the fail-safe, yes.
> 
> However, any paired symbol could do, and parens do not actually play
> nice within a command in shell (the shell keep trying to capture the
> parens for its own parsing).
> 
> The usual alternative was to use {}. I'd vote for this.

Yes braces are also OK.

> > > > > There could be a note that after the comma past the eventual
> > > > > "driver=xxxx" pair, the syntax is driver-specific and might not follow
> > > > > the equal-separated key/value pair syntax.
> > > > 
> > > > Please give an example.
> > > 
> > > bus=vdev/driver=failsafe,dev(bus=pci,id=00:02.0),fd(/some/file/)
> > > 
> > > Here, without some kind of "end-of-parameter" mark, fd() would be
> > > considered as a new parameter of the sub-device 00:02.0
> > 
> > Right.
> > I think an equal sign is missing between "dev" and parenthesis.
> > 
> > > --------------
> > > 
> > > And while I'm at it, there is an ambiguity that might need to be defined
> > > before the whole shebang is implemented: whether the parameters
> > > positions are meaningful or not. Currently some drivers might consider their
> > > parameters to mean different things depending on their order of appearance.
> > > 
> > > It could help to explicitly say that the order is asemic and should not
> > > be considered by drivers.
> > > 
> > > Why this is important: I think that depending on the new rte_devargs
> > > representation, it could be beneficial to have a canonical representation
> > > of an rte_devargs: given an arbitrary string given by users, the devargs
> > > could then be rewritten in a determinist way, which would help implementing
> > > comparison, assignment, and some other operations.
> > > 
> > > However, for this canonicalization to be possible, order needs to be
> > > explicitly said to be meaningless.
> > 
> > Good idea. I vote for meaningless ordering, except the first property
> > of each category, which describes the category.
> 
> Agreed.

  reply	other threads:[~2018-01-17  9:43 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-16 14:50 Yuanhan Liu
2018-01-16 16:33 ` Mcnamara, John
2018-01-16 23:19 ` Gaëtan Rivet
2018-01-16 23:22   ` Thomas Monjalon
2018-01-16 23:46     ` Gaëtan Rivet
2018-01-17  0:03       ` Thomas Monjalon
2018-01-17  9:37         ` Gaëtan Rivet
2018-01-17  9:43           ` Thomas Monjalon [this message]
2018-01-17 10:11 ` Gaëtan Rivet
2018-01-17 10:54   ` Thomas Monjalon
2018-01-17 12:34 ` Ferruh Yigit
2018-01-18  7:35   ` Yuanhan Liu
2018-01-18  8:46     ` Thomas Monjalon
2018-01-18  9:46       ` Gaëtan Rivet
2018-01-23 12:46         ` Yuanhan Liu
2018-01-23 14:29           ` Thomas Monjalon
2018-01-23 16:08             ` Gaëtan Rivet
2018-01-23 17:22               ` Thomas Monjalon
2018-01-23 17:37                 ` Gaëtan Rivet
2018-01-23 18:12                   ` Thomas Monjalon
2018-01-24 15:24               ` Yuanhan Liu
2018-01-24 16:51                 ` Thomas Monjalon
2018-01-24  6:43             ` Yuanhan Liu
2018-01-24  8:19               ` Thomas Monjalon
2018-01-24  9:28                 ` Yuanhan Liu
2018-01-24 10:21                   ` Thomas Monjalon
2018-01-24 10:36                     ` Yuanhan Liu
2018-01-24 10:37                       ` Thomas Monjalon
2018-01-24 15:04                         ` Yuanhan Liu
2018-01-24 16:57                           ` Thomas Monjalon
2018-01-25 14:41                             ` Yuanhan Liu
2018-01-25 14:58                               ` Thomas Monjalon
2023-06-08 22:51 ` Stephen Hemminger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3880793.9nSlzmWI4v@xps \
    --to=thomas@monjalon.net \
    --cc=dev@dpdk.org \
    --cc=gaetan.rivet@6wind.com \
    --cc=yliu@fridaylinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).