From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754775Ab1KWQ7c (ORCPT ); Wed, 23 Nov 2011 11:59:32 -0500 Received: from mail2.gnudd.com ([213.203.150.91]:64900 "EHLO mail.gnudd.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752592Ab1KWQ7b (ORCPT ); Wed, 23 Nov 2011 11:59:31 -0500 Date: Wed, 23 Nov 2011 17:54:52 +0100 From: Alessandro Rubini To: dave.martin@linaro.org Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, mmarek@suse.cz, greg@kroah.com, rusty@rustcorp.com.au Subject: Re: [RFC PATCH 2/2] modpost: use config and ELF sections to build file2alias Message-ID: <20111123165452.GA24139@mail.gnudd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: GnuDD, Device Drivers, Embedded Systems, Courses In-Reply-To: <20111123162842.GC2050@localhost.localdomain> References: <20111123162842.GC2050@localhost.localdomain> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > I'm not the expert here, but I have a few comments that might be > useful. Yes, thanks. > In files which define multiple bus types, there's no reason to put them > all in the same array, so we can avoid the explicit boilerplate. Nice catch, I'll do as you suggest. > For myself, I have some misgivings about using this kind of toolchain > trick where it is not needed -- though this is partly a matter of taste. > > (To clarify, I think this stuff is only needed where the resulting > [...] This is needed because the bus abstraction and module autoloading is so useful that we have a lot of uses, and they are ever increasing. As said, in my current workgroup we have two new buses in the works. > The problem to be solved here is essentially a source transofmration > and should be possible to do straightforwardly with an autogenerated > include file, a couple of Makefile rules and some scripting or > preprocessor tricks to paste the relevant entries into a common > array. But the result is more hackish than this. ELF sections are well understood and widely used in this environment, so the solution is proved working. Scripting otherwise is an unneeded complication, as every user will have to know a new technique, which may break in the future (e.g. gmake 3.82 broke some makefiles: each new trick is a new risk). > Otherwise, this series looks like a sensible evolution to me. thanks /alessandro