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 6BB771B2B8 for ; Wed, 17 Jan 2018 01:04:22 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 37F6420C74; Tue, 16 Jan 2018 19:04:22 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 16 Jan 2018 19:04:22 -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=UQU8pjV1FcmEm8lEBxfel2xa2W RHQYOtRG23zrvzx90=; b=XlBA3GBljuqghrOuZ1wr2TYljAxEjgyHQk+qlE6t3B PzT9z//2coqBfZy999kj+ecCHiy2cQ0HOcYzsN0eH1dZEcuGamrGSrL2HhAjXBvK ulaXHFBTmNLRK8m17Kl4MR64XVehBdolBDSVqQwPyvcqS6AjpOrhnpsQjU+bc1Dp g= 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=UQU8pj V1FcmEm8lEBxfel2xa2WRHQYOtRG23zrvzx90=; b=HTaJZryZSWUh0PBoOWjVYM fAwZ9Pd4U3X0QNcyA/VMNUPwTD46GL+FWOPSZKUT8yG0vgs3FjJXtc8m8wDDd8CL oL/+BjuxrWuk6jhQrvsVNuni+he1Nk6LeELngc47l+yyj9/A/RvdIhnBb9lyznYH f4VzekiNC+6BxC947P+U/OBN+jCMsGFuUowYYo6hF953wgdyn2bOi8zAaIqpoeci Sx+Z1HMVH38NG+GKFdRi0MM+WyD2Sn6APtP3jwfiLGeiY+FcFfx5e08mYcwxc63l 2M2j4W0Q5J0eJ5IMlji1KGJ2/AadCL1YjxTqJQHse+PELSsAUQSzQjTESn5aqsIA == 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 D05B47E322; Tue, 16 Jan 2018 19:04:21 -0500 (EST) From: Thomas Monjalon To: =?ISO-8859-1?Q?Ga=EBtan?= Rivet Cc: Yuanhan Liu , dev@dpdk.org Date: Wed, 17 Jan 2018 01:03:50 +0100 Message-ID: <4760784.sYhQ8SkhdB@xps> In-Reply-To: <20180116234633.i4j2itsuzxk7kl35@bidouze.vm.6wind.com> References: <1516114218-21501-1-git-send-email-yliu@fridaylinux.org> <5324030.qnTS7Rnbq7@xps> <20180116234633.i4j2itsuzxk7kl35@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 00:04:23 -0000 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 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 flexibilit= y. > >=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 substrings > following the aforementioned syntax. >=20 > 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. >=20 > =3D 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. Maybe we just want to allow using marker characters inside values. 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. > > > There could be a note that after the comma past the eventual > > > "driver=3Dxxxx" pair, the syntax is driver-specific and might not fol= low > > > 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/file/) >=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 Right. I think an equal sign is missing between "dev" and parenthesis. > -------------- >=20 > 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 th= eir > parameters to mean different things depending on their order of appearanc= e. >=20 > It could help to explicitly say that the order is asemic and should not > 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 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 implementi= ng > comparison, assignment, and some other operations. >=20 > 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.