From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 6EAB12B96 for ; Thu, 21 Apr 2016 14:13:21 +0200 (CEST) Received: from [107.15.76.160] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1atDTv-0007F2-48; Thu, 21 Apr 2016 08:13:18 -0400 Date: Thu, 21 Apr 2016 08:13:14 -0400 From: Neil Horman To: David Marchand Cc: "dev@dpdk.org" , Thomas Monjalon , Stephen Hemminger , "Richardson, Bruce" , Panu Matilainen , Christian Ehrhardt Message-ID: <20160421121314.GB22931@hmsreliant.think-freely.org> References: <1453120248-28274-1-git-send-email-david.marchand@6wind.com> <1461156236-25349-1-git-send-email-david.marchand@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Score: -1.0 (-) X-Spam-Status: No Subject: Re: [dpdk-dev] [PATCH v3 00/13] kill global pci device id list X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 12:13:21 -0000 On Thu, Apr 21, 2016 at 10:07:51AM +0200, David Marchand wrote: > On Wed, Apr 20, 2016 at 2:43 PM, David Marchand > wrote: > > - not storing the pci ids in a dedicated section anymore, pci drivers are > > exported and parsed by a quickly written (and naive) tool > > Rethinking about this, this part won't do. > Stripping symbols breaks it, and I had to go some gymnastics to get > the symbols, while having exported information sanitised as strings in > a dedicated section constructed at build time would be saner. > Yes, this really sounds like modinfo ... > > Volunteers ? modinfo (or a tool likes it), requires more gymnastics in the actual code than what we have. It requires the auto-generation of extra c code that gets linked into its own section (which implies the need for a linker script). Not saying its a bad idea, its a pretty good one, just that its alot of work. We might be able to do something a bit more simple, perhaps convert the macros to strings that we can extract with a tool? not sure Neil > > > -- > David Marchand >