linux-kernel - Re: [GIT PULL] omap changes for v2.6.39 merge window

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: <1301671655.28467.52.camel@e102144-lin.cambridge.arm.com>
Date:	Fri, 01 Apr 2011 16:27:35 +0100
From:	Will Deacon <will.deacon@....com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Ingo Molnar <mingo@...e.hu>, david@...g.hm,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Nicolas Pitre <nico@...xnic.net>,
	Tony Lindgren <tony@...mide.com>,
	Catalin Marinas <Catalin.Marinas@....com>,
	lkml <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	David Brown <davidb@...eaurora.org>,
	linux-omap@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [GIT PULL] omap changes for v2.6.39 merge window

Hi Arnd,

On Fri, 2011-04-01 at 14:54 +0100, Arnd Bergmann wrote:
> I would actually suggest a different much more radical start: Fork the way
> that platforms are managed today, and start an alternative way of setting
> up boards and devices together with the proven ARM core kernel infrastructure,
> based on these observations (please correct me if some of them they don't make
> sense):
> 
> 1. The core arch code is not a problem (Russell does a great job here)
> 2. The platform specific code contains a lot of crap that doesn't belong there
>    (not enough reviewers to push back on crap)
> 3. The amount of crap in platform specfic files is growing exponentially,
>    despite the best efforts of a handful of people to clean it up.
> 4. Having one source file per board does not scale any more.
> 5. Discoverable hardware would solve this, but is not going to happen
>    in practice.
> 6. Board firmware would not solve this and is usually not present.
> 7. Boot loaders can not be trusted to pass valid information
> 8. Device tree blobs can solve a lot of the problems, and nobody has
>    come up with a better solution.

Right, so this is directly related to point (5) because in essence FDT
is a way to make undiscoverable hardware discoverable by probing the
tree. The `it's just data' mantra sums it up nicely.

> 9. All interesting work is going into a handful of platforms, all of which
>    are ARMv7 based.

I think starting out ARMv7-only might make this more manageable but
there are still shed loads of pre-v7 chips out there which we should try
not to break.

> 10. We do not want to discontinue support for old boards that work fine.

[...]

> Based on these assumptions, my preferred strategy would be to a new
> mach-nocrap directory with a documented set of rules (to be adapted when
> necessary):

This is a nice idea, but I don't think it's entirely practical:

> * Strictly no crap
>  * No board files

I don't understand how you can handle `early quirks' without board
files. Does this follow on from Linus' suggestion about moving code out
of the kernel and into the bootloader?

Realistically, I don't think you will ever get away from board files.
The trick is probably to make them as small as possible and common to as
many boards as possible (like the platforms directory for PowerPC).

>  * No hardcoded memory maps
>  * No lists of interrupts and GPIOs

This is largely just data, so should be do-able once this stuff isn't
needed at compile-time (which is becoming the case with stuff like
dynamic p2v).

Will

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