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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20111123171444.GB20345@localhost.localdomain>
Date:	Wed, 23 Nov 2011 17:14:44 +0000
From:	Dave Martin <dave.martin@...aro.org>
To:	Alessandro Rubini <rubini@...pv.it>
Cc:	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	mmarek@...e.cz, greg@...ah.com, rusty@...tcorp.com.au
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/