2.6.19 -mm merge plans

Jeff Garzik · External Since: Mar 05, 2006 Posts: 1496

Linus Torvalds wrote:
> One of the things that I think the current model has excelled at is how it
> really changed peoples behaviour, simply because they knew and understood
> the rules.
>
> I think the "big merges in the first two weeks, and a -rc1 after, and no
> new code after that" rule has been working because it brought everybody in
> on the same page.

I definitely agree with all that.

I simply argue that, the more time that passes between releases, the
MORE BUGS that appear in the next release.

After -rc1, you reach a point of diminishing returns where users don't
re-test Release Candidates, developers move on to new code rather than
fix bugs, and we all move into a limbo where 2.6.X-rcY doesn't see much
activity, but the huge "merge snowball" in -mm builds and builds and builds.

As an aside, if a release is getting held up by some key bugs or
regressions, I think it's more than fair for Andrew to loudly shame said
developers into action. "The following nincompoops are holding up the
release: Jeff Garzik [bug #1222, #3391], Greg KH [bug #9987, #4418], ..."

Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Andrew Morton · External Since: Aug 22, 2004 Posts: 2442

On Thu, 21 Sep 2006 14:33:41 -0400
Jeff Garzik wrote:

> I think it's more than fair for Andrew to loudly shame said
> developers into action. "The following nincompoops are holding up the
> release: Jeff Garzik [bug #1222, #3391], Greg KH [bug #9987, #4418], ..."

I don't have the bandwidth to do that work, alas. I know how to do it, and
have tried to do it, but a) it's dull and b) even I get tired of whining at
people all the time.

The good news is that google is prepared to hire someone to sit next to me
and do it, but I haven't got off my ass and written the job description
yet.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Adrian Bunk · External Since: Nov 08, 2004 Posts: 2232

On Thu, Sep 21, 2006 at 02:33:41PM -0400, Jeff Garzik wrote:
> Linus Torvalds wrote:
> >One of the things that I think the current model has excelled at is how it
> >really changed peoples behaviour, simply because they knew and understood
> >the rules.
> >
> >I think the "big merges in the first two weeks, and a -rc1 after, and no
> >new code after that" rule has been working because it brought everybody in
> >on the same page.
>
>
> I definitely agree with all that.
>
> I simply argue that, the more time that passes between releases, the
> MORE BUGS that appear in the next release.
>
> After -rc1, you reach a point of diminishing returns where users don't
> re-test Release Candidates, developers move on to new code rather than
> fix bugs, and we all move into a limbo where 2.6.X-rcY doesn't see much
> activity, but the huge "merge snowball" in -mm builds and builds and builds.

This "there is not enough testing by users" is simply not true:

Even the kernel Bugzilla that contains only a small subset of all bug
reports contains 78 (sic) open bugs reported against 2.6.18-rc kernels [1].

Not all of them are regressions, but this shows that users are testing
-rc kernels and reporting bugs.

> As an aside, if a release is getting held up by some key bugs or
> regressions, I think it's more than fair for Andrew to loudly shame said
> developers into action. "The following nincompoops are holding up the
> release: Jeff Garzik [bug #1222, #3391], Greg KH [bug #9987, #4418], ..."
>
> Jeff

cu
Adrian

[1] including bugs reported against 2.6.18-rc?-mm? and 2.6.18-rc?-git*

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Diego Calleja · External Since: May 22, 2006 Posts: 50

El Thu, 21 Sep 2006 21:46:04 +0200,
Adrian Bunk escribió:

> Even the kernel Bugzilla that contains only a small subset of all bug
> reports contains 78 (sic) open bugs reported against 2.6.18-rc kernels [1].

I suspect that not many people is subscribed to the bugzilla mailing list,
not surprising since the URLs doesn't seem to be in the tree Smile

After fixing my english, I wonder if the following patch could be applied...

Signed-off-by: Diego Calleja

--- 2.6/Documentation/HOWTO.OLD 2006-09-21 22:14:06.000000000 +0200
+++ 2.6/Documentation/HOWTO 2006-09-21 22:36:17.000000000 +0200
@@ -374,6 +374,26 @@ of information is needed by the kernel d
problem.

+Managing bug reports
+--------------------
+
+One of the best ways to put into practice your hacking skills is by fixing
+bugs reported by other people. Not only you will help to make the kernel
+more stable, you'll learn to fix real world problems and you will improve
+your skills, and other developers will be aware of your presence. Fixing
+bugs is one of the best ways to get merits between other developers, because
+not many people like wasting time fixing other people's bugs.
+
+To work in the already reported bug reports, go to http://bugzilla.kernel.org.
+If you want to be advised of the future bug reports, you can subscribe to the
+bugme-new mailing list (only new bug reports are mailed here) or to the
+bugme-janitor mailing list (every change in the bugzilla is mailed here)
+
+ http://lists.osdl.org/mailman/listinfo/bugme-new
+ http://lists.osdl.org/mailman/listinfo/bugme-janitors
+
+
+
Mailing lists
-------------

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jeff Garzik · External Since: Mar 05, 2006 Posts: 1496

Adrian Bunk wrote:
> Not all of them are regressions, but this shows that users are testing
> -rc kernels and reporting bugs.

I never claimed otherwise. But every release turns up plenty of bugs
that are otherwise uncaught, because its inevitable that a much larger
set of users tests the full releases.

Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Adrian Bunk · External Since: Nov 08, 2004 Posts: 2232

On Thu, Sep 21, 2006 at 04:38:21PM -0400, Jeff Garzik wrote:
> Adrian Bunk wrote:
> >Not all of them are regressions, but this shows that users are testing
> >-rc kernels and reporting bugs.
>
>
> I never claimed otherwise. But every release turns up plenty of bugs
> that are otherwise uncaught, because its inevitable that a much larger
> set of users tests the full releases.

My point is that we don't lack testers and bug reports - we lack people
fixing bugs.

> Jeff

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Randy.Dunlap · External Since: May 15, 2006 Posts: 372

On Thu, 21 Sep 2006 22:37:10 +0200 Diego Calleja wrote:

> El Thu, 21 Sep 2006 21:46:04 +0200,
> Adrian Bunk escribió:
>
> > Even the kernel Bugzilla that contains only a small subset of all bug
> > reports contains 78 (sic) open bugs reported against 2.6.18-rc kernels [1].
>
> I suspect that not many people is subscribed to the bugzilla mailing list,
> not surprising since the URLs doesn't seem to be in the tree Smile

>
> After fixing my english, I wonder if the following patch could be applied...
>
> Signed-off-by: Diego Calleja
>
> --- 2.6/Documentation/HOWTO.OLD 2006-09-21 22:14:06.000000000 +0200
> +++ 2.6/Documentation/HOWTO 2006-09-21 22:36:17.000000000 +0200
> @@ -374,6 +374,26 @@ of information is needed by the kernel d
> problem.
>
>
> +Managing bug reports
> +--------------------
> +
> +One of the best ways to put into practice your hacking skills is by fixing
> +bugs reported by other people. Not only you will help to make the kernel
> +more stable, you'll learn to fix real world problems and you will improve
> +your skills, and other developers will be aware of your presence. Fixing
> +bugs is one of the best ways to get merits between other developers, because

s/between/among/ Smile

Acked-by: Randy Dunlap

> +not many people like wasting time fixing other people's bugs.
> +
> +To work in the already reported bug reports, go to http://bugzilla.kernel.org.
> +If you want to be advised of the future bug reports, you can subscribe to the
> +bugme-new mailing list (only new bug reports are mailed here) or to the
> +bugme-janitor mailing list (every change in the bugzilla is mailed here)
> +
> + http://lists.osdl.org/mailman/listinfo/bugme-new
> + http://lists.osdl.org/mailman/listinfo/bugme-janitors
> +
> +
> +
> Mailing lists
> -------------
>
> -

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jeff Garzik · External Since: Mar 05, 2006 Posts: 1496

Bill Davidsen wrote:
> I think it would help if you went back to using meaningful names for
> releases, because 2.6.19-test1 is pretty clearly a test release even to
> people who can't figure out if a number is odd or even. Then after
> people stop reporting show stoppers, change to rc numbers, where rc
> versions are actually candidates for release without known major bugs.

Actually, considering our group of developers, I think "-rc" has been
remarkably successful at staying on the "bug fixes only" theme.

Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

David Miller · External Since: Sep 25, 2006 Posts: 1746

From: Jeff Garzik
Date: Thu, 21 Sep 2006 17:33:27 -0400

> Bill Davidsen wrote:
> > I think it would help if you went back to using meaningful names for
> > releases, because 2.6.19-test1 is pretty clearly a test release even to
> > people who can't figure out if a number is odd or even. Then after
> > people stop reporting show stoppers, change to rc numbers, where rc
> > versions are actually candidates for release without known major bugs.
>
> Actually, considering our group of developers, I think "-rc" has been
> remarkably successful at staying on the "bug fixes only" theme.

I agree.

But even on that note I would love to have a release cycle where I
didn't merge any new features and could work entirely on the bugs
that never get worked on.

Sure, I'll still be merging new features into my "N + 1" tree.
But my pure interactions with Linus's tree can focus entirely
on bug fixing, and I really want an environment in which to
concentrate on that exclusively.

I think the even/odd idea is great, personally. And if this
makes some people have to wait a little bit longer for their
favorite feature to get merged, that's tough. Smile

I truly think we need to move towards a more stability minded
mode and back off on the new features just a bit.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Martin Bligh · External Since: May 15, 2006 Posts: 40

>>If a device driver wants "DMAable" memory, and thus does a ZONE_DMA
>>allocation, and we've moved all its memory from ZONE_DMA to ZONE_NORMAL
>>(as I think you're proposing doing for PPC64 (and ia64?)), then the
>>allocation will fail.
>
> I would not presume proposing anything for PPC64 and left everything the
> way it is. The arch people can control if they want ZONE DMA or not and
> the default is to leave things as is. If PPC64 wants to go ZONE_DMAless
> then the arch code needs to be modified not refer to ZONE_DMA anymore and
> if that works then we can switch CONFIG_ZONE_DMA off for PPC64. See the
> patches in mm for examples how other arches have done it.

Sorry, there was some confusion then, maybe I misunderstood one of your
earlier emails.

>>So are we saying that no driver code should be calling with GFP_DMA
>>(a quick grep turns up 148 instances under driver/), that if they do
>>they should only work on specific architectures (some instances were
>>s390-only drivers)? If so, should we not be removing the definiton of
>>GFP_DMA itself if ZONE_DMA is config'ed out, so that it fails at
>>compile time, rather than runtime?
>
>
> This was covered at length before. Removing all GFP_DMA references would
> require extensive #ifdefs. The limited patch in mm is only neutering
> GFP_DMA for arches that do not need it. If an arch has removed its definition of
> CONFIG_ZONE_DMA then __GFP_DMA will be ignored in the page allocator.

Just ignoring GFP_DMA in the allocator seems like a horrible violation
to me. GFP_DMA means "give me memory from ZONE_DMA". We're both well
aware that the whole concept of ZONE_DMA doesn't make much sense, but
still, that's what it does.

So if you just put all of memory in ZONE_DMA for your particular
machine, and bumped the DMA limit up to infinity, we wouldn't need
any of these patches, right? Which would also match what the other
arches do for this (eg PPC64).

Seems like a much simpler way of solving the problem to me. Or do you
think that won't work for some reason?

M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Trond Myklebust · External Since: May 16, 2006 Posts: 286

On Wed, 2006-09-20 at 20:39 -0700, Andrew Morton wrote:
> On Wed, 20 Sep 2006 17:55:33 -0400
> Trond Myklebust wrote:
>
> > On Wed, 2006-09-20 at 13:54 -0700, Andrew Morton wrote:
> >
> > > add-newline-to-nfs-dprintk.patch
> > > fs-nfs-make-code-static.patch
> > >
> > > NFS queue -> Trond.
> > >
> > > The NFS git tree breaks autofs4 submounts. Still.
> >
> > I still suspect that is due to a misconfigured selinux setup on your
> > machine. If autofs4 expects to be able to do mkdir() on your NFS
> > partition (something which in itself is wrong), then selinux should be
> > configured to allow it to do so.
> >
> > Anyhow, does reverting the patch
> >
> > http://kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6...t;a=com
> >
> > 'fix' the issue for you?
> >
>
> yes.

Hmm... but you aren't seeing it with a clean 2.6.18 kernel?

Cheers,
Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Fengguang Wu · External Since: Jun 05, 2006 Posts: 48

On Wed, Sep 20, 2006 at 01:54:38PM -0700, Andrew Morton wrote:
>
> The readahead code is complex, I'm unconvinced that it has a lot of benefit
> and Wu has gone quiet. Will drop.

Sorry, I've been putting efforts to meet the deadline of the google
SoC project "Rapid linux desktop startup through pre-caching", which
still can not be called success for now. And there's my pending paper
work...

I should be able to come back and concentrate on the readahead patch
after one month, whether it be dropped for now. I guess it can be
further improved in complexity and performance. It also needs a good
document for the overall design and benefits. And sure the
performance numbers Smile

Regards,
Fengguang Wu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Andrew Morton · External Since: Aug 22, 2004 Posts: 2442

On Fri, 22 Sep 2006 07:46:37 +0800
Fengguang Wu wrote:

> On Wed, Sep 20, 2006 at 01:54:38PM -0700, Andrew Morton wrote:
> >
> > The readahead code is complex, I'm unconvinced that it has a lot of benefit
> > and Wu has gone quiet. Will drop.
>
> Sorry, I've been putting efforts to meet the deadline of the google
> SoC project "Rapid linux desktop startup through pre-caching", which
> still can not be called success for now. And there's my pending paper
> work...

Oh, OK.

That's a neat thing to be working on.

> I should be able to come back and concentrate on the readahead patch
> after one month, whether it be dropped for now. I guess it can be
> further improved in complexity and performance. It also needs a good
> document for the overall design and benefits. And sure the
> performance numbers Smile

I'll hang onto the patches then - they're causing little maintenance
trouble for me.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Bill Davidsen · External Since: Jan 07, 2005 Posts: 321

Jeff Garzik wrote:
> Bill Davidsen wrote:
>> I think it would help if you went back to using meaningful names for
>> releases, because 2.6.19-test1 is pretty clearly a test release even
>> to people who can't figure out if a number is odd or even. Then after
>> people stop reporting show stoppers, change to rc numbers, where rc
>> versions are actually candidates for release without known major bugs.
>
>
> Actually, considering our group of developers, I think "-rc" has been
> remarkably successful at staying on the "bug fixes only" theme.
>
Perhaps I misread what Linus said, the issue I was suggesting be
addressed was one of clarity to the testers, not the developers. The
releases identified as test would be for evaluation, while the ones
identified as rc would really be candidates with no "fix before next
version" bugs known. I would think that between test releases some bugs
could be fixed, but new features could be added. That would encourage
more active testing without overly slowing the development process.

Having used that for a long time for 2.2 and 2.4 I think there's quite a
track record of that nomenclature being clear to the users.

--
Bill Davidsen
Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one errors occurs during
wildcard (glob) expansion.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Christoph Lameter · External Since: Sep 29, 2006 Posts: 1367

On Thu, 21 Sep 2006, Martin Bligh wrote:

> Just ignoring GFP_DMA in the allocator seems like a horrible violation
> to me. GFP_DMA means "give me memory from ZONE_DMA". We're both well
> aware that the whole concept of ZONE_DMA doesn't make much sense, but
> still, that's what it does.

We agreed that the definition of ZONE_DMA is not consistent across
architectures.

The concept of ZONE_DMA makes only sense in terms of an architectures
definition if a memory boundary (MAX_DMA_ADDRESS) exists for special DMA
devices not able to reach all of memory. If we do not have ZONE_DMA then the
architecture has to remove the definition of CONFIG_ZONE_DMA
and with that action told us that it is allowable to ignore GFP_DMA since
all devices can do DMA to all of memory (and all of memory is memory
without a border which is of course in ZONE_NORMAL).

GFP_DMA like GFP_HIGHMEM and GFP_DMA32 means give me memory from the zone
if its there. If not (the arch has no such memory) we fall back to ZONE_NORMAL.

This is fully consistent with established uses.

> So if you just put all of memory in ZONE_DMA for your particular
> machine, and bumped the DMA limit up to infinity, we wouldn't need
> any of these patches, right? Which would also match what the other
> arches do for this (eg PPC64).

That would mean abusing ZONE_DMA for a purpose it was not intended for.
ZOME_DMA is used to partition memory for a DMA not for covering all of
memory. That works yes but it shows a misunderstanding of the purpose for
which ZONE_DMA was created.

Also if you would do that then ZONE_NORMAL would be empty and you would
not be able to reach the goal of a system with a single zone. The slab
allocator gets thoroughly confused and waste pages allocating
memory in different slabs for ZONE_NORMAL and ZONE_DMA but they end up in
the same ZONE_DMA. Various other bits and pieces of the VM behave in
strange way but it works mostly. Seems that you got lucky but this should
be fixed.

ZONE_NORMAL is DMAable. GFP_DMA has never meant this is for DMA but it has
always meant this is for a special restricted DMA zone. That is also why
you have GFP_DMA32. Both GFP_DMA and GFP_DMA32 select special restricted
memory areas for handicapped DMA devices that are not able to reach all of
memory. Neither should cover all of memory.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Andi Kleen · External Since: Jul 07, 2006 Posts: 1925

Andrew Morton writes:
>
> Jeff: "I want faster release cycles because <no reason given>"

I think i would also prefer somewhat faster cycles, simple to get
more regular full scale testing.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Russell King · External Since: May 18, 2006 Posts: 480

On Thu, Sep 21, 2006 at 06:05:39PM -0400, Dave Jones wrote:
> We already have some subsystems that do once-per-release merges,
> and then let fixes build up in their out-of-tree SCM for months
> until the next window. It won't necessarily get worse, but unless
> everyone is participating in the odd/even rules, we won't get
> the benefits that it would offer.

I'm heading in that direction (once-per-release merges) actually.

On one hand, I'm credited with the ARM architecture being one of the
best maintained embedded architectures in the kernel tree. On the
other hand, that appears to be winding Linus up due to the regular
merge requests, which were happening maybe once or twice a week.

Linus seems to be of the opinion that, if anyone can't wait a number
of months for their patch to get into mainline, then they shouldn't
be involved in this game. The content of the tree which that comment
was made at contained (imho) just bug fixes.

At the moment, we're up to 528kB (initial commit Aug 21st) of IOP3xx
and S3C24xx machine updates, and various other developments. As for
the other trees, MMC (9kB since Aug 27) and serial (20kB since Aug 30)
but neither have been looked at for a while, certainly not post 2.6.18.
I'm not even responding to mail about these because I haven't been even
thinking about them yet.

As far as -mm getting these, I have asked Andrew to pull this tree in
the past, but whenever I rebase the trees (eg, when 2.6.18 comes out)
and fix up the rejects, Andrew seems to have a hard time coping. I
guess Andrew finds it too difficult to handle my devel branches.

Where I go from here I'm not sure - I'm running out of ideas for
correct "Care and Operation of (my) Linus Torvalds", except becoming
one of the Bad People who only merge _lots_ of changes once in a blue
moon.

So, what I'm going to be doing this cycle is essentially sitting on
stuff for quite some time and not really caring about where in the
release cycle mainline actually is. (Anyone remember Linus moaning
at various people for doing exactly this? Eg, ALSA people?) It
pains me to do this because it's obviously not the _correct_ thing
to do, but I don't see any other way of keeping Linus happy. And this
does mean giving up all hope of getting anything in mainline.

As far as my future, I will be handing MMC off to Pierre Ossman during
this cycle (there are other reasons for doing this which Pierre has been
aware of for some time.)

I'll also be dropping my serial tree entirely - I have no idea who could
stand in for serial, so there's going to be no real "hand over" for that.
I do have some outstanding in-progress changes which aren't really ready,
but those will probably end up in /dev/null (in much the same way that my
in-progress changes for PCMCIA ended up in a similar place when I handed
that tree over.)

So, it's going to mean that the only thing I'm going to be caring about
post-2.6.19 is ARM again.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

David Woodhouse · External Since: Feb 27, 2005 Posts: 318

On Wed, 2006-09-20 at 13:54 -0700, Andrew Morton wrote:
>
> mtd-maps-ixp4xx-partition-parsing.patch
> fix-the-unlock-addr-lookup-bug-in-mtd-jedec-probe.patch
> mtd-printk-format-warning.patch
> fs-jffs2-jffs2_fs_ih-removal-of-old-code.patch
> drivers-mtd-nand-au1550ndc-removal-of-old-code.patch
>
> MTD queue -> dwmw2

Merged, with the exception of the unlock addr one which I'm still not
sure about -- about to investigate harder.

Also merged are
pci-mtd-switch-to-pci_get_device-and-do-ref-counting.patch and
avr32-mtd-unlock-flash-if-necessary.patch

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

David Woodhouse · External Since: Feb 27, 2005 Posts: 318

On Fri, 2006-09-22 at 10:24 +0100, David Woodhouse wrote:
> On Wed, 2006-09-20 at 13:54 -0700, Andrew Morton wrote:
> >
> > mtd-maps-ixp4xx-partition-parsing.patch
> > fix-the-unlock-addr-lookup-bug-in-mtd-jedec-probe.patch
> > mtd-printk-format-warning.patch
> > fs-jffs2-jffs2_fs_ih-removal-of-old-code.patch
> > drivers-mtd-nand-au1550ndc-removal-of-old-code.patch
> >
> > MTD queue -> dwmw2
>
> Merged, with the exception of the unlock addr one which I'm still not
> sure about -- about to investigate harder.

I just reverted Randy's printk format 'fix', since rq->flags _is_ an
unsigned long, so changing from %ld to %d actually _introduces_ a
warning.

Randy, that's the second time I recall recently that I've ended up
reverting a printk format fix from you -- what are you doing? How did
you manage to get the warning you reported:

drivers/mtd/mtd_blkdevs.c:72: warning: long int format, different type arg (arg 2)

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jan Engelhardt · External Since: Jun 24, 2004 Posts: 1116

>> > mtd-maps-ixp4xx-partition-parsing.patch
>> > fix-the-unlock-addr-lookup-bug-in-mtd-jedec-probe.patch
>> > mtd-printk-format-warning.patch
>> > fs-jffs2-jffs2_fs_ih-removal-of-old-code.patch
>> > drivers-mtd-nand-au1550ndc-removal-of-old-code.patch
>> >
>> > MTD queue -> dwmw2
>>
>> Merged, with the exception of the unlock addr one which I'm still not
>> sure about -- about to investigate harder.
>
>I just reverted Randy's printk format 'fix', since rq->flags _is_ an
>unsigned long, so changing from %ld to %d actually _introduces_ a
>warning.

If it is an unsigned long, it should neither be %ld nor %d, but %lu.

Jan Engelhardt
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/