Linux 2.6.34-rc1
Linus Torvalds
It's out there now. I still have a few trees I already got pull requests
for, and that I want to look over a bit more (ceph, gdb tree etc), and
it's possible that I've just overlooked some other pull request.
So if you feel like you sent me a pull request bit might have been
over-looked, please point that out to me, but in general the merge window
is over. And as promised, if you left your pull request to the last day of
a two-week window, you're now going to have to wait for the 2.6.35 window.
As usual, there's tons of changes, with about 50% of the changes being
under drivers/. With an additional 5% in sound/, which has its own
subdirectory, and 10% being firmware/, we're looking at about two thirds
being driver-related.
Of the remaining, about half is arch updqates (mainly arm, mips, ppc, sh
and x86), and half is "rest". Which includes things like a new filesystem
(logfs - as mentioned, there's another one pending too, so we might have
two new ones in 2.6.34).
All in all, about 850 developers involved so far (there migth be a few
dups there, I didn't check too closely), 6500+ files changed, 400,000+
lines added, ~175,000 lines deleted. Too much to really summarize, in
other words.
The thing that bit me, and might bite a few others, is that if you're
using Nouveau, you'll have to install new libdrm/nouveau_drv versions.
Other than that, if something doesn't work, please holler!
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jiri Slaby
> It's out there now. I still have a few trees I already got pull requests
> for, and that I want to look over a bit more (ceph, gdb tree etc), and
> it's possible that I've just overlooked some other pull request.
>
> So if you feel like you sent me a pull request bit might have been
> over-looked, please point that out to me
Hi, yes, the writable limits tree:
http://lkml.org/lkml/2010/3/5/219
Maybe it was ignored on purpose. Either way, I would like to know to
decide whether to drop it from -next or not and wait for a 2.6.35 merge
window.
thanks,
--
js
Mike Frysinger
> It's out there now. I still have a few trees I already got pull requests
> for, and that I want to look over a bit more (ceph, gdb tree etc), and
> it's possible that I've just overlooked some other pull request.
>
> So if you feel like you sent me a pull request bit might have been
> over-looked, please point that out to me, but in general the merge window
> is over. And as promised, if you left your pull request to the last day of
> a two-week window, you're now going to have to wait for the 2.6.35 window.
i was traveling the last few weeks doing training and got back this
weekend. was finishing up the Blackfin tree now, but i guess i missed
the window huh ...
-mike
Jan Kara
> for, and that I want to look over a bit more (ceph, gdb tree etc), and
> it's possible that I've just overlooked some other pull request.
http://lkml.indiana.edu/hypermail/linux/kernel/1003.0/02186.html).
I've rebased the tree on top of 2.6.34-rc1 so could you please pull
now?
The full pull request for your convenience:
could you please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-udf-2.6.git for_linus
to get:
Akinobu Mita (1):
udf: use ext2_find_next_bit
Jan Kara (2):
udf: Fix unalloc space handling in udf_update_inode
udf: Do not read inode before writing it
The diffstat is
fs/udf/balloc.c | 49 +------------------------------------------------
fs/udf/inode.c | 34 +++++++++++++++++-----------------
2 files changed, 18 insertions(+), 65 deletions(-)
Honza
--
Jan Kara <ja...@suse.cz>
SuSE CR Labs
Randy Dunlap
> > It's out there now. I still have a few trees I already got pull requests
> > for, and that I want to look over a bit more (ceph, gdb tree etc), and
> > it's possible that I've just overlooked some other pull request.
> It seems you haven't pulled my UDF tree (requested on Thursday -
> http://lkml.indiana.edu/hypermail/linux/kernel/1003.0/02186.html).
> I've rebased the tree on top of 2.6.34-rc1 so could you please pull
> now?
> The full pull request for your convenience:
>
> could you please pull from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-udf-2.6.git for_linus
>
> to get:
>
> Akinobu Mita (1):
> udf: use ext2_find_next_bit
>
> Jan Kara (2):
> udf: Fix unalloc space handling in udf_update_inode
> udf: Do not read inode before writing it
>
> The diffstat is
>
> fs/udf/balloc.c | 49 +------------------------------------------------
> fs/udf/inode.c | 34 +++++++++++++++++-----------------
> 2 files changed, 18 insertions(+), 65 deletions(-)
I have no objections, fwiw, but please change the $subject line...
---
~Randy
Jan Kara
> On Tue, 9 Mar 2010 17:28:04 +0100 Jan Kara wrote:
> > > It's out there now. I still have a few trees I already got pull requests
> > > for, and that I want to look over a bit more (ceph, gdb tree etc), and
> > > it's possible that I've just overlooked some other pull request.
> > It seems you haven't pulled my UDF tree (requested on Thursday -
> > http://lkml.indiana.edu/hypermail/linux/kernel/1003.0/02186.html).
> > I've rebased the tree on top of 2.6.34-rc1 so could you please pull
> > now?
> > The full pull request for your convenience:
> >
> > could you please pull from
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-udf-2.6.git for_linus
> >
> > to get:
> >
> > Akinobu Mita (1):
> > udf: use ext2_find_next_bit
> >
> > Jan Kara (2):
> > udf: Fix unalloc space handling in udf_update_inode
> > udf: Do not read inode before writing it
> >
> > The diffstat is
> >
> > fs/udf/balloc.c | 49 +------------------------------------------------
> > fs/udf/inode.c | 34 +++++++++++++++++-----------------
> > 2 files changed, 18 insertions(+), 65 deletions(-)
>
> I have no objections, fwiw, but please change the $subject line...
Honza
--
Jan Kara <ja...@suse.cz>
SUSE Labs, CR
Jiri Kosina
> > It's out there now. I still have a few trees I already got pull requests
> > for, and that I want to look over a bit more (ceph, gdb tree etc), and
> > it's possible that I've just overlooked some other pull request.
> >
> > So if you feel like you sent me a pull request bit might have been
> > over-looked, please point that out to me
>
> Hi, yes, the writable limits tree:
> http://lkml.org/lkml/2010/3/5/219
>
> Maybe it was ignored on purpose. Either way, I would like to know to
> decide whether to drop it from -next or not and wait for a 2.6.35 merge
> window.
Seems like this was neither commented on, nor merged. I don't see any
serious objections to having this merged having been raised anywhere ...
Any word on this?
--
Jiri Kosina
SUSE Labs, Novell Inc.
Pavel Machek
> > > It's out there now. I still have a few trees I already got pull requests
> > > for, and that I want to look over a bit more (ceph, gdb tree etc), and
> > > it's possible that I've just overlooked some other pull request.
> > >
> > > So if you feel like you sent me a pull request bit might have been
> > > over-looked, please point that out to me
> >
> > Hi, yes, the writable limits tree:
> > http://lkml.org/lkml/2010/3/5/219
> >
> > Maybe it was ignored on purpose. Either way, I would like to know to
> > decide whether to drop it from -next or not and wait for a 2.6.35 merge
> > window.
>
> Seems like this was neither commented on, nor merged. I don't see any
> serious objections to having this merged having been raised anywhere ...
>
> Any word on this?
Maybe noone cars? Try to push it through akpm?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html