From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f176.google.com (mail-wr0-f176.google.com [209.85.128.176]) by dpdk.org (Postfix) with ESMTP id D71F02BE1 for ; Wed, 17 Jan 2018 10:38:02 +0100 (CET) Received: by mail-wr0-f176.google.com with SMTP id g38so14951939wrd.2 for ; Wed, 17 Jan 2018 01:38:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=0iEnmqi8HdYzBFCJ6hQiCEP92QIkni/ZZTQ9Gd/bK0k=; b=kRYxBqGFpZcoLhXoOeicImjdPvP5iP0d9bWESRRuYCfjGuFzpAFBuEGOM7/bLjHYr4 PyQuwRy3dVC10UZKGapmYG3f2wUZysu6n/P2IcZMrcrgjnK1frq0mlOzSf+MCXKKbfzc i9D5pxmnWIqCZJIYZEZbTrSkbPYHm330GYAyJRRyso3ig8wqSd6ny4aXGk1xxswoYbP8 Go7Xr6DXVPrJgb7vlDa1oKFNy6uVWd+mY0DFH84Qb6w+ErldnOIrCxRl9YRTSRCWM8zy lcN9p49n8aj/etgEIRZhHMNXufYaj3bKewW6xStBfnVcYmKf5G5u/aPtjUH/ErvyQNO2 3IwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=0iEnmqi8HdYzBFCJ6hQiCEP92QIkni/ZZTQ9Gd/bK0k=; b=ZwJfC8ersSjoUJBInFuumSGKBk3shvOOqnSpyXclFmPNpzXzAGuDNVTp6lA2wDBqTv KHCPvtErOtndYGFkbfwCAEMjJQlNouIrHkApUN13QDXBjVYXy63+K/DkUn5iqMIKO9u9 bkXU7JipA/fW1CtzmqJ4vZHrsCAWAcMO8V4iTgdL+ULOx8e9dgE34QgsVQxYieHRH6xB cRk1rxsFLJY0rTVsA5HEMxVetCmxT7ptCwnOrTziRE9nD6/1r7pLrjSdS2q5GFfuVNXn djhqY/Fk6tzg0PEPH6i9SnvMtqxcRHvtkO683X98yt5p15KPHm6mbeN5UTERg1MLmF5B 205w== X-Gm-Message-State: AKwxytdiljwbl1ymJXLPOqLkrDDJ2D6kFOjLQWlzExcR+0TbtrSoe5QM QyhTe514g15zFd9rQnt6I5dfMw== X-Google-Smtp-Source: ACJfBotA4nQnmCeeUcOFabFLapAkH8DYOm63QBDruwuo418LdoH6NQ4ZNd2C5+4YDX8iiMHQjUB4Lw== X-Received: by 10.223.173.21 with SMTP id p21mr1866306wrc.182.1516181882297; Wed, 17 Jan 2018 01:38:02 -0800 (PST) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id c54sm4602928wrg.68.2018.01.17.01.38.01 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 17 Jan 2018 01:38:01 -0800 (PST) Date: Wed, 17 Jan 2018 10:37:49 +0100 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Thomas Monjalon Cc: Yuanhan Liu , dev@dpdk.org Message-ID: <20180117093749.upv2k6ew5tbvwdsp@bidouze.vm.6wind.com> References: <1516114218-21501-1-git-send-email-yliu@fridaylinux.org> <5324030.qnTS7Rnbq7@xps> <20180116234633.i4j2itsuzxk7kl35@bidouze.vm.6wind.com> <4760784.sYhQ8SkhdB@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4760784.sYhQ8SkhdB@xps> User-Agent: NeoMutt/20170113 (1.7.2) 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:38:03 -0000 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. > 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? > 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. > > > > 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. -- Gaëtan Rivet 6WIND