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: <AANLkTim6zg-U6HtAQbqnENqoK7x8erXSqOuTFVC0YE5r@mail.gmail.com>
Date:	Wed, 30 Mar 2011 14:02:20 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Nicolas Pitre <nico@...xnic.net>
Cc:	Arnd Bergmann <arnd@...db.de>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Tony Lindgren <tony@...mide.com>,
	David Brown <davidb@...eaurora.org>,
	lkml <linux-kernel@...r.kernel.org>,
	linux-arm-kernel@...ts.infradead.org, linux-omap@...r.kernel.org,
	Catalin Marinas <catalin.marinas@....com>
Subject: Re: [GIT PULL] omap changes for v2.6.39 merge window

On Wed, Mar 30, 2011 at 1:41 PM, Nicolas Pitre <nico@...xnic.net> wrote:
>
> If in your mind "competitors" == "morons" then you might be right.

There's a difference between "competition" and "do things differently
just to be difficult".

> Trying to rely on bootloaders doing things right is like saying that x86
> should always rely on the BIOS doing things right.

No. Not at all.

The problem with firmware/BIOS is that it's set in stone and closed-source.

I'm suggesting splitting out the crazy part into a separate project
that does this. Open-source. Like a mini-kernel. Because the thing is,
the main kernel doesn't care, and _shouldn't_ care. Those board files
are just noise.

The long-term situation should be that you should be able to have ONE
binary kernel "just work". That's where we are on x86. Really.

Without that kind of long-term view, where do you think ARM is going
to be in five years?

>> almost *SIXTY* percent of all arch updates were to ARM code.
>
> Absolutely not!  You have 14% going to OMAP code which happens to be
> under arch/arm/ but there is nothing ARM specific in there.  If OMAP was
> using a PPC or a MIPS core then you'd have the same result except under
> arch/powerpc or arch/mips.  There is very little in terms of ARM
> specific peculiarities under arch/arm/mach-omap2/ in fact.

But that's my point - the problem is all the crazy board crap.

I've never claimed that this is about the ARM cpu (which has it's own
issues, but that's a separate rant entirely). It's about the broken
infrastructure.

Now, some of it is quite understandable - ie real drivers for real
hardware. But a _lot_ of it seems to be just descriptor tables, and
I'm getting the very strong feeling that ARM people aren't even
_trying_ to make it sane, and trying to standardize things, or trying
to aim for the whole notion of "one kernel image, with much more hw
description done elsewhere".

Sure, you'll fundamentally always need several images (due to the
afore-mentioned crazy CPU architecture flaws - arm6 vs arm7 vs
armxyz), but I'm looking at the future, and arch/arm will get
_totally_ unmaintainable unless you guys have a plan for getting out
of the crazy hole you are in now.

arch/arm is already about 3x the size of arch/x86. And it's pretty
much all the crazy infrastructure afaik. timer chips, irq chips, gpio
differences - crap like that.

And the fact that you don't even seem to UNDERSTAND the problem, and
think that it's ok, and that continued future explosion of this is all
fine makes me even more nervous.

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