[lkml]   [2011]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [GIT PULL] omap changes for v2.6.39 merge window
    On Wed, 30 Mar 2011, Linus Torvalds wrote:

    > On Wed, Mar 30, 2011 at 1:41 PM, Nicolas Pitre <> 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".

    Absolutely. We've seen that from some proprietary software companies.

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

    Sure, but important noise nevertheless. As long as the noise is
    confined to a limited set of .c files I'm happy. OTOH I have very
    little hope for a separate project that would only deal with that noise.
    That will simply never fly, even less so as an Open Source project.
    The insentive for people to work on such thing simply aren't there as
    that is totally uninteresting and without any rewards.

    Furthermore, this does create pain. you have to make things in sync
    between the kernel and the mini-kernel (let's call it bootloader). In
    practice the bootloader is always maintained separately from the kernel,
    on its own pace and with its own release schedule. Trying to
    synchronize independent projects is really painful as you know already,
    otherwise the user space for perf would still be maintained separately
    from the kernel, right?

    Now, when there is a bug in one of the clock settings, or one clock
    is missing for that new kernel driver to work properly, the
    bootloader would have to be fixed, revalidated, and the fix deployed
    separately but still in addition to the kernel. This process still adds
    to the pain such that what people do in those cases is simply to hack
    the driver code in the kernel. Instead, the OMAP folks created a table
    to abstract them into something more manageable.

    And here's the final catch. Most of those clocks are often derived from
    each other in a tree structure inside the SOC. And for power saving
    reasons, some crazy people want to dynamically change the config for
    those clocks at run time according to the required frequency for given
    loads, turn them off when possible, and of course turn the parent clock
    off as well if all the children clocks are themselves turned off. So
    the kernel has NO CHOICE but to be fully aware of them.

    Then comes power domains with the cascade of regulators and so forth,
    again all software controlled. Add to the mix the different sleep
    states that can be derived from that, which is far more sophisticated
    than ACPI states on Intel. And in some cases, the hardware capabilities
    are there but people still didn't find the optimal way to drive them, so
    research is still on-going software wise. And obviously those SOC
    vendors do compete on that front since power consumption is the killing
    weapon these days. No wonder why they are so different from each other
    with all that "board crap".

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

    But X86 is peanuts. Really. There was one machine called the IBM PC at
    some point that everybody cloned, and the rest was totally irrelevant.
    Then came that thing called Windows that reinforced this hardware
    monoculture as it was used for the ultimate conformance testing. This
    is damn easy in that case to produce a kernel that works virtually

    On ARM there is simply not such thing as a single machine design to
    clone, and a closed source test bench to design for.

    And this is orthogonal to this discussion anyway, as having in-kernel
    clock tables is not incompatible with a single kernel binary. Dropping
    at runtime those clock tables that are irrelevant to the currently
    running hardware is not rocket science.

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

    ARM is going to still be relevant simply because they now have Linux
    that they can modify to suit their latest changes. That's one thing
    with Open Source which can be good or bad: full hardware compatibility
    is no longer an issue since the software can be adapted at will.

    Still... there are on-going efforts to consolidate things amongst all
    the ARM vendors. The ARM architecture is standardizing more and more
    stuff in the whole stack in every revision. But they won't standardize
    everything otherwise they'll kill that competing ecosystem.

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

    Let's see how we can fix it then. Trying to shovel the problem away
    won't help the situation. Those ARM vendors are crazy for sure. But
    it's not a relatively few merge conflicts compared to the volume of
    changes that will make us flinch, right?

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

    That work is happening. It is not ready. I'm not against it but I
    remain sceptical. I still think that a self contained kernel is more

    Still, because ARM is just a CPU architecture, those SOC vendors will
    always have something new to differenciate themselves from the other SOC
    vendors. And that cannot be described in a table alone. The power
    management hardware from TI will still require separate _executable_
    code from the Freescale one, or the Samsung one, or the Nvidia one, or
    the Qualcomm one, or the Marvell one, yada yada. And I really don't
    want to see that code turned into some vendor provided buggy ACPI
    bytecode or similar.

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

    Indeed. And I expect it to grow even bigger. Be warned.

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

    I do understand the problem. And so far, the way we scaled is to have
    TI people care about the OMAP code, Freescale people care about the iMX
    code, and so on. If one of them produces crap code then so it is, and
    the other vendor is totally unaffected, which is why I'm not too
    nervous. Blaming a merge conflict on the entire ARM ecosystem just
    because one team was large enough to have separate people doing
    different things that intersected into the clock table is blowing things
    totally out of proportion.

    And if those hardware vendors are still in business in the future, and
    apparently new ones are joining in, then the arch/arm/ directory will
    continue to gain weight. And on ARM, Linux is very very successful
    that's all.

     \ /
      Last update: 2011-03-31 01:35    [W:0.037 / U:9.908 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site