[lkml]   [2011]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Linux 3.2-rc1
    On Tue, Nov 8, 2011 at 3:10 AM, Linus Torvalds
    <> wrote:
    > So it's been two weeks since 3.1, and you know how it works by now.
    > I have to say, this wasn't my favorite merge window ever. I really
    > wanted to take only things that had been in -next, but verifying it
    > was fairly painful, since a lot of the trees had been rebased, and the
    > ones that hadn't been rebased often had some extra patches that still
    > showed up when I did my "git log linux-next..FETCH_HEAD" thing.
    > On the whole, most of it was all good, and I didn't really end up
    > complaining to people. I'm pretty sure that there were trees I
    > shouldn't have let through, but the majority really had been in -next.
    > The other point of irritation was that there really was a lot of stuff
    > that came in yesterday and basically treated the merge window as some
    > kind of high-tech limbo dance. If it hadn't been for a few trees I
    > wanted to pull, I had actually planned to do the -rc1 release Sunday
    > afternoon instead, just to cut those annoying last-minute pull
    > requests off.
    > And some trees didn't get pulled. You know who you are, and you can
    > try to appeal to my softer side if you think it was unfair. Of course,
    > if you *do* find my softer side, please tell my wife and kids too,
    > they'll be thrilled.
    > But the main reason some trees didn't get pulled was that they
    > generated long flame-wars, and I just felt like I really didn't need
    > the aggravation this time around, especially as I knew I had plenty
    > other trees to pull.
    > What *did* get pulled? A lot. The diffstat is huge, and is full of
    > renames. The network drivers got re-organized, which is a big chunk of
    > the renames, but there are architecture cleanups and re-organizations
    > there too (UML and some arm sub-architectures, for example) adding
    > their own set of renames. Along with some staging drivers that got
    > upgraded to non-staging etc etc.
    > Which brings me to a question I already asked on G+ - do people really
    > need the old-fashioned patches? The -rc1 patch is about 22MB gzip-9'd,
    > and part of the reason is that all those renames cause big
    > delete/create diffs. We *could* use git rename patches, but then you'd
    > have to apply them with "git apply" rather than the legacy "patch"
    > executables. But as it is, the patch is almost a third of the size of
    > the tar-ball, which makes me wonder if there's even any point to such
    > a big patch?
    > Apart from the re-organization, there is really just a lot of changes
    > all over. It's about 75% drivers (and that's without the renames
    > counted as big delete/create events - in the traditional diff, more
    > than 90% is drivers), 15% arch, and 10% "rest" (mainly fs and net -
    > with header file changes showing up in the statistics too).
    > What doesn't even show up in the stats is the VM changes, although
    > those may well be the most noticeable core stuff. It may be fairly
    > small, but it's rather more core, and has the potential to affect
    > everybody. People have been working on writeback tuning, and the whole
    > IO-less dirty balancing. So now foreground writeback should be a thing
    > of the past. Let's see how that all works out.
    > Have fun, give it a good testing. There shouldn't be anything hugely
    > scary in there, but there *is* a lot of stuff. The fact that 3.1
    > dragged out did mean that this ended up being one of the bigger merge
    > windows, but I'm not feeling *too* nervous about it.
    >                 Linus

    Dell laptop support (and I'd suspect other drivers using LED support)
    doesn't build with undefined LED-related functions, as in:

    ERROR: "led_classdev_unregister" [drivers/platform/x86/dell-laptop.ko]
    ERROR: "led_classdev_register" [drivers/platform/x86/dell-laptop.ko] undefined!
    make[1]: *** [__modpost] Error 1
    make: *** [modules] Error 2

    It's enough to configure NEW_LEDS (unneeded in 3.1.0) to allow the build to go
    through; maybe NEW_LEDS should be auto-selected in Kconfig by drivers that
    make use of led_classdev_* functions ?


     "There's always a siren singing you to shipwreck"

       (Radiohead, "There There")
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2011-11-08 15:55    [W:0.026 / U:6.304 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site