From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755306Ab1KWROu (ORCPT ); Wed, 23 Nov 2011 12:14:50 -0500 Received: from mail-yw0-f46.google.com ([209.85.213.46]:36010 "EHLO mail-yw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754870Ab1KWROt (ORCPT ); Wed, 23 Nov 2011 12:14:49 -0500 Date: Wed, 23 Nov 2011 17:14:44 +0000 From: Dave Martin To: Alessandro Rubini 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: <20111123171444.GB20345@localhost.localdomain> References: <20111123162842.GC2050@localhost.localdomain> <20111123165452.GA24139@mail.gnudd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111123165452.GA24139@mail.gnudd.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 23, 2011 at 05:54:52PM +0100, Alessandro Rubini wrote: > > 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. You may have misunderstood -- putting tables in special sections and doing a link-time merge is the thing that we don't necessarily to do here. We do need the final merged table for use by file2alias.c; we just don't necessarily have to construct it in that way. Orthogonalising the addition of new buses to the module framework is clearly a good idea though -- I'm not disupting that. > > 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 I'm not entirely convinced that it _can't_ be done in a less hack-ish way... but I confess that my own attempts did end up in a bit of a mess. So I can't really argue my point there. > 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). As I said, it's partly a matter of personal taste. I'm happy to go with other people's judgement. Sticking with something people are used to certainly has value. Cheers ---Dave