From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by dpdk.org (Postfix) with ESMTP id 044CA3DC for ; Tue, 21 Aug 2018 11:03:24 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id B74792A5; Tue, 21 Aug 2018 05:03:23 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 21 Aug 2018 05:03:24 -0400 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=p5ZyML09FDyAagWQJVn6sh7Td4 cZ6YSjw7A+XVzGQJ0=; b=YP0yzCA47xRM+cmMlv4lwhnaG6r87bZi4FG2hwGq0I sHzW1HpJCCAesgzLKRaoE06BEWsr1V7LyNAwX0gHX229GZrRTciiFaIe2Zmie5EV 7HYhjDx3XrkMtPeYovv5L71gl7wpDJGboOJmHF7r8PWDHxhh4rTnjBcYX3uFqTqy s= 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=fm3; bh=p5ZyML 09FDyAagWQJVn6sh7Td4cZ6YSjw7A+XVzGQJ0=; b=VYewSpXVHIh68PqE/NmzqA BiBrEmh8JVdck05RocC0IqhPqH9RLwUdmkmHb7V7eZHHqOZ0FpdS/HucZPiPkIbu 1B2GA9ydfAL43004tUWIVCiRWWHWDhw3V7r0wjcn2FBvxa3G9H6Z99R0Ku94zIvU 7yHQ37EWVfyPiNhktv2AFv0pSz+BewOueoMBDoXJrGQzGK5/16WRDCkWnEqXjQMZ vZLZ7G86TxbbyXu3GKHaukCm1b8H40RNtsCF5DumppcbASNEQm3N+PfcPaKNmZg6 RpPZZRqB4+VNcamoRd+OLJFAXylu7maWr6MHTOBwSJABYRicMIePVx1MtXjpTc4A == X-ME-Proxy: 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 33A9FE4014; Tue, 21 Aug 2018 05:03:22 -0400 (EDT) From: Thomas Monjalon To: Neil Horman Cc: dev@dpdk.org, "Rao, Nikhil" Date: Tue, 21 Aug 2018 11:03:21 +0200 Message-ID: <1584735.cRL6gNcrux@xps> In-Reply-To: <954d81fa-e977-ac7e-8c5f-fbe2fd186bf4@intel.com> References: <20180816110801.5378-1-nhorman@tuxdriver.com> <954d81fa-e977-ac7e-8c5f-fbe2fd186bf4@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] check-symbol-change: relax rule for identifying a section 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: Tue, 21 Aug 2018 09:03:25 -0000 17/08/2018 05:03, Rao, Nikhil: > On 8/16/2018 4:38 PM, Neil Horman wrote: > > It was reported recently that some patches that add symbols to an > > existing EXPERIMENTAL section of a version map file generate errors > > because the check-symbol-change script was identifying the section as > > "@@" rather than EXPERIMENTAL. This was fairly clearly due to the fact > > that the rule identifying the version section expected the whole section > > to be added, rather than having it already exist, with only new symbols > > being added to the existing section. This led the match rule to misread > > the format of that line and pull the wrong word out of it. > > > > The fix is to relax the rule slightly. Rather than assume that the > > section must exist on a line that was added, allow the section name to > > be set by any line that ends in a '{', which should be correct, given > > our coding practices. The section name is then extracted as the next to > > the last word on the line ( $(NF-1) ). > > > > Tested by the reporter with good results > > > > Reported-by: nikhil.rao@intel.com > > Signed-off-by: Neil Horman > > > Tested-by: Nikhil Rao Applied, thanks