From mboxrd@z Thu Jan 1 00:00:00 1970 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) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3EE6420D16; Wed, 17 Jan 2018 04:43:55 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 17 Jan 2018 04:43:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=I2FxB1Pu2DGq+NRBrcnhJjcxE2 8zrTrhlvx8AVo7F2o=; b=CbGFjhAErJs7Om9398ULxVraxLkpExhhhal21fJ/XE ikbrGHn9BJNJ3Ly09M1aXbqzevpvJ/sLEm6cVvaYiiHDib/qWWwKu5z7+9jXj+YB VVCjrD0Pt1Bkqio7RD+g2LUWbTm/6RXe5FgTqcGc4vE4MULMgrN2ZYYjIlxG9/V7 A= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=I2FxB1 Pu2DGq+NRBrcnhJjcxE28zrTrhlvx8AVo7F2o=; b=sXeci6Lq4+qIBtjwEiOKkY kiOLXv++bhDyB7b4mgBzgYGLfTTcdT19MUgl4jOWKExKQx/D0M6OtBn66CkltWoH 59L/bHRDH9RnsiwIdI31lO94ugd9CJbCuWC2FTgMzXeqACQb+eMOkIobGUuBotYq X46sz3Rws7L59d7vU0roPgNHHIppNIG9Rdj86oPQiQLqOL1iTruaOjtChUhngxxO lzK2LOfYflyrSL3huNghSR1rle4eOE4yTpMkF+vQiNEBzQ4h7bZCgr+omTyMex5n +nfdoYDL8DgQ8S56SSxkF0Hbr9wdzdM1L4ACdve2bGe4QJzy/zksmiBs12TzdfCA == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id D50E47E43A; Wed, 17 Jan 2018 04:43:54 -0500 (EST) From: Thomas Monjalon To: =?ISO-8859-1?Q?Ga=EBtan?= Rivet Cc: Yuanhan Liu , dev@dpdk.org Date: Wed, 17 Jan 2018 10:43:23 +0100 Message-ID: <3880793.9nSlzmWI4v@xps> In-Reply-To: <20180117093749.upv2k6ew5tbvwdsp@bidouze.vm.6wind.com> References: <1516114218-21501-1-git-send-email-yliu@fridaylinux.org> <4760784.sYhQ8SkhdB@xps> <20180117093749.upv2k6ew5tbvwdsp@bidouze.vm.6wind.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [dpdk-dev] [PATCH] doc: document the new devargs syntax X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2018 09:43:56 -0000 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.