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]

Date:	Wed, 23 Nov 2011 17:54:52 +0100
From:	Alessandro Rubini <rubini@...pv.it>
To:	dave.martin@...aro.org
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

> 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.

> 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
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).

> Otherwise, this series looks like a sensible evolution to me.

thanks
/alessandro
--
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/