lkml.org 
[lkml]   [2011]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 2/2] modpost: use config and ELF sections to build file2alias
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


\
 
 \ /
  Last update: 2011-11-23 18:17    [W:0.030 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site