From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH] doc: document the new devargs syntax Date: Wed, 17 Jan 2018 10:43:23 +0100 Message-ID: <3880793.9nSlzmWI4v@xps> References: <1516114218-21501-1-git-send-email-yliu@fridaylinux.org> <4760784.sYhQ8SkhdB@xps> <20180117093749.upv2k6ew5tbvwdsp@bidouze.vm.6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: Yuanhan Liu , dev@dpdk.org To: =?ISO-8859-1?Q?Ga=EBtan?= Rivet Return-path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id CA20D1B026 for ; Wed, 17 Jan 2018 10:43:55 +0100 (CET) In-Reply-To: <20180117093749.upv2k6ew5tbvwdsp@bidouze.vm.6wind.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 17/01/2018 10:37, Ga=EBtan Rivet: > Hi Thomas, >=20 > On Wed, Jan 17, 2018 at 01:03:50AM +0100, Thomas Monjalon wrote: > > 17/01/2018 00:46, Ga=EBtan Rivet: > > > On Wed, Jan 17, 2018 at 12:22:43AM +0100, Thomas Monjalon wrote: > > > > 17/01/2018 00:19, Ga=EBtan Rivet: > > > > > It might be a nitpick, but the driver specific properties might n= ot > > > > > follow the key/value pair syntax. At least for the fail-safe, a c= ustom > > > > > parsing needs to happen. I think vdev in general will need flexib= ility. > > > >=20 > > > > What is more flexible than key/value? > > >=20 > > > fail-safe does not need something more flexible, but different. > > > It needs to define substrings describing whole devices, thus substrin= gs > > > following the aforementioned syntax. > > >=20 > > > I choose to use ( and ) as markers of beginning and end of the "speci= al > > > sub-device part that we need to skip for the moment". In the end, I n= eed > > > 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. > > >=20 > > > =3D separated key/value pair does not allow for this (or with very > > > convoluted additional rules to the syntax). > >=20 > > OK, I agree we need beginning and end markers. > > I wonder whether we should consider devargs as a specific case of value. >=20 > Not sure I follow: you would want to consider a different syntax whether > we are defining or identifying a device? >=20 > 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. >=20 > 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). >=20 > Do you have a justification for restricting drivers parameters? Why > couldn't this only be structured by commas (or any separators), and other= wise > 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. >=20 > This was the initial reason for using parens in the fail-safe, yes. >=20 > 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). >=20 > 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=3Dxxxx" pair, the syntax is driver-specific and might not= follow > > > > > the equal-separated key/value pair syntax. > > > >=20 > > > > Please give an example. > > >=20 > > > bus=3Dvdev/driver=3Dfailsafe,dev(bus=3Dpci,id=3D00:02.0),fd(/some/fil= e/) > > >=20 > > > Here, without some kind of "end-of-parameter" mark, fd() would be > > > considered as a new parameter of the sub-device 00:02.0 > >=20 > > Right. > > I think an equal sign is missing between "dev" and parenthesis. > >=20 > > > -------------- > > >=20 > > > And while I'm at it, there is an ambiguity that might need to be defi= ned > > > before the whole shebang is implemented: whether the parameters > > > positions are meaningful or not. Currently some drivers might conside= r their > > > parameters to mean different things depending on their order of appea= rance. > > >=20 > > > It could help to explicitly say that the order is asemic and should n= ot > > > be considered by drivers. > > >=20 > > > Why this is important: I think that depending on the new rte_devargs > > > representation, it could be beneficial to have a canonical representa= tion > > > of an rte_devargs: given an arbitrary string given by users, the deva= rgs > > > could then be rewritten in a determinist way, which would help implem= enting > > > comparison, assignment, and some other operations. > > >=20 > > > However, for this canonicalization to be possible, order needs to be > > > explicitly said to be meaningless. > >=20 > > Good idea. I vote for meaningless ordering, except the first property > > of each category, which describes the category. >=20 > Agreed.