[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, Mar 30, 2011 at 10:06 AM, Arnd Bergmann <> wrote:
    > I'm still new to the ARM world, but I think one real problem is the way
    > that all platforms have their own trees with a very flat hierarchy --
    > a lot of people directly ask Linus to pull their trees, and the main
    > way to sort out conflicts is linux-next. The number of platforms in the
    > ARM arch is still increasing, so I assume that this only gets worse.

    As far as I'm concerned, the biggest issuee is that some of the ARM
    crap is just CRAP. It's idiotic tables that get updated by multiple
    people, and in totally nonsensical ways. When I see conflicts in those
    damn clock-data files, I just go mental. Those files are an

    Why the hell is the clock-data for fifty (number taken out of my ass)
    different clocking rules in one array? And why do we have eight
    different files of that kind of crap for omap2?

    THAT is an example of something that is totally and utterly screwed
    up. Those kinds of random board-level detail files abound in the ARM
    tree. They should either be in a per-board file, or (much better) the
    ARM people should have standardized this ten f*cking years ago, and
    put it in a bootloader or something that just initializes the crap so
    that the kernel doesn't have to have random tables like that at all.

    ARM right now i a nightmare, and most of it is because ARM hardware
    manufacturers are morons. But the way the ARM tree is then laid out
    has made that even more painful, and the decision to put all the crazy
    board details in the kernel tables instead of trying to have a
    per-board boot loader that fills in the details is just crazy.

    Look at the dirstat for arch/ in just the current merge window
    (cut-off at 5% just to not get too much):

    [torvalds@i5 linux]$ git diff -C --dirstat=5 --cumulative v2.6.38.. arch
    14.0% arch/arm/mach-omap2/
    5.8% arch/arm/plat-mxc/include/mach/
    6.3% arch/arm/plat-mxc/
    57.1% arch/arm/
    5.4% arch/m68k/
    9.6% arch/unicore32/
    6.9% arch/x86/
    100.0% arch/

    almost *SIXTY* percent of all arch updates were to ARM code. And
    that's despite the fact that one of those architectures (unicore32) is
    a totally new architecture, and despite m68k having gone through a
    first-level unification of nommu and mmu code!

    And was this just a fluke? No. Doing the same for 2.3.37..38 gives
    58.3% for arch/arm (and in that release we had a blackfin unification
    effort, otherwise arm would have been an even bigger percentage).

    That's ridiculous. It's entirely due to the whole f*cked-up arm ecosystem.

    Something needs to be done. A small part is to make sure the source
    code is more hierarchical, so that we don't have those crazy shared
    data-files that are ugly as hell and get conflicts because different
    boards all think they need to care.

    But the larger problem is that somebody really REALLY needs to think
    about how to get those crazy board details out of the kernel entirely.
    Having per-board drivers for real hardware is sane - having to have
    per-board detail files for clock chips is just crazy. Split off that
    thing a "Linux ARM second-stage bootloader" project that has the
    per-board tables or something. Don't pollute the main kernel with
    crazy details like this.

    Because as far as I can tell, most of that board support really is
    about crazy details that the kernel shouldn't even care about. Come up
    with a table that describes them, have one common parsing routine, and
    push the table into a bootloader. And get rid of having to add a board
    file for every crazy random piece of hardware that nobody really cares

    Or something.


     \ /
      Last update: 2011-03-30 21:25    [W:0.023 / U:18.572 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site