Messages in this thread | | | Date | Wed, 23 Nov 2011 17:14:44 +0000 | From | Dave Martin <> | Subject | Re: [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
| |