[RFC PATCH 2/2] modpost: use config and ELF sections to build file2alias

[dave.martin@linaro.org (Dave Martin)]

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