2.6.19 -mm merge plans

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

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/

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

On Fri, 2006-09-22 at 12:42 +0200, Jan Engelhardt wrote:
> If it is an unsigned long, it should neither be %ld nor %d, but %lu.

It'll never be negative.

--
dwmw2

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

Haavard Skinnemoen · External Since: Jul 06, 2006 Posts: 200

On Wed, 20 Sep 2006 13:54:38 -0700
Andrew Morton <akpm DeleteThis @osdl.org> wrote:

> AVR32 architecture. Will fold into a single patch, and will merge.

Thanks a lot Smile

I will do my best to ensure it stays in good shape
during the -rc series.

> avr32-mtd-static-memory-controller-driver-try-2.patch
> avr32-mtd-at49bv6416-platform-device-for-atstk1000.patch
> avr32-mtd-unlock-flash-if-necessary.patch
>
> MTD changes for avr32. Will send to dwmw2.

It might actually make more sense to fold the first two into the avr32
architecture patch. Especially now that David has picked up the third
one (which ended up not being AVR32-specific at all.)

The static memory controller driver isn't really specific to MTD
anyway, it should be equally useful for all kinds of external
memory-mapped devices including CompactFlash.

Haavard
-
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/

Christoph Hellwig · External Since: May 16, 2006 Posts: 757

> ecryptfs-fs-makefile-and-fs-kconfig.patch
> ecryptfs-fs-makefile-and-fs-kconfig-kconfig-help-update.patch
> ecryptfs-documentation.patch
> ecryptfs-makefile.patch
> ecryptfs-main-module-functions.patch
> ecryptfs-header-declarations.patch
> ecryptfs-superblock-operations.patch
> #ecryptfs-superblock-operations-ecryptfs-build-fix.patch
> ecryptfs-dentry-operations.patch
> ecryptfs-file-operations.patch
> #ecryptfs-vs-streamline-generic_file_-interfaces-and-filemap.patch
> #ecryptfs-vs-streamline-generic_file_-interfaces-and-filemap-fix.patch
> ecryptfs-inode-operations.patch
> ecryptfs-mmap-operations.patch
> ecryptfs-mmap-operations-fix.patch
> ecryptfs-keystore.patch
> ecryptfs-crypto-functions.patch
> ecryptfs-crypto-functions-mutex-fixes.patch
> fs-ecryptfs-possible-cleanups.patch
> ecryptfs-debug-functions.patch
> ecryptfs-alpha-build-fix.patch
> ecryptfs-convert-assert-to-bug_on.patch
> ecryptfs-remove-pointless-bug_ons.patch
> ecryptfs-remove-unnecessary-null-checks.patch
> ecryptfs-rewrite-ecryptfs_fsync.patch
> ecryptfs-overhaul-file-locking.patch
> ecryptfs-remove-lock-propagation.patch
> ecryptfs-dont-muck-with-the-existing-nameidata-structures.patch
> ecryptfs-asm-scatterlisth-linux-scatterlisth.patch
> ecryptfs-support-for-larger-maximum-key-size.patch
> ecryptfs-add-codes-for-additional-ciphers.patch
> ecryptfs-unencrypted-key-size-based-on-encrypted-key-size.patch
> ecryptfs-packet-and-key-management-update-for-variable-key-size.patch
> ecryptfs-add-ecryptfs_-prefix-to-mount-options-key-size-parameter.patch
> ecryptfs-set-the-key-size-from-the-default-for-the-mount.patch
> ecryptfs-check-for-weak-keys.patch
> ecryptfs-add-define-values-for-cipher-codes-from-rfc2440-openpgp.patch
> ecryptfs-convert-bits-to-bytes.patch
> ecryptfs-more-elegant-aes-key-size-manipulation.patch
> ecryptfs-more-intelligent-use-of-tfm-objects.patch
> ecryptfs-remove-debugging-cruft.patch
> ecryptfs-get_sb_dev-fix.patch
> ecryptfs-validate-minimum-header-extent-size.patch
> ecryptfs-validate-body-size.patch
> ecryptfs-validate-packet-length-prior-to-parsing-add-comments.patch
> ecryptfs-use-the-passed-in-max-value-as-the-upper-bound.patch
> ecryptfs-change-the-maximum-size-check-when-writing-header.patch
> ecryptfs-print-the-actual-option-that-is-problematic.patch
> ecryptfs-add-a-maintainers-entry.patch
> ecryptfs-partial-signed-integer-to-size_t-conversion-updated-ii.patch
> ecryptfs-graceful-handling-of-mount-error.patch
> inode-diet-move-i_pipe-into-a-union-ecryptfs.patch
> inode-diet-eliminate-i_blksize-and-use-a-per-superblock-default-ecryptfs.patch
> streamline-generic_file_-interfaces-and-filemap-ecryptfs.patch
> ecryptfs-fix-printk-format-warnings.patch
> ecryptfs-associate-vfsmount-with-dentry-rather-than-superblock.patch
> ecryptfs-mntput-lower-mount-on-umount_begin.patch
> vfs-make-filldir_t-and-struct-kstat-deal-in-64-bit-inode-numbers-ecryptfs.patch
> make-kmem_cache_destroy-return-void-ecryptfs.patch
> ecryptfs-inode-numbering-fixes.patch
> ecryptfs-versioning-fixes.patch
> ecryptfs-versioning-fixes-tidy.patch
>
> Will fold into a single patch and will then merge.

Please add a

Not-Acked-By: Christoph Hellwig <hch.TakeThisOut@lst.de>

here as you don't seem to listen to any of the comments I had against
the current state and I want this clearly documented.
-
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/

Dave Jones · External Since: Mar 15, 2005 Posts: 720

On Fri, Sep 22, 2006 at 09:35:42AM +0100, Russell King wrote:
> 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.

Hmm. Some trees do seem to get pulled more often than others.
Linus, is there a upper limit on the number of times you want
to see pull requests? It strikes me as odd, so I'm wondering
if there are some crossed wires here.

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

Has Andrew commented on why this is proving to be more of a problem?
I've done regular rebases of cpufreq/agpgart (admittedly, they don't
reject hardly ever unless Len has ACPI bits touching cpufreq) without
causing too much headache.

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

That doesn't sound like the right way to fix the 'caring for my Linus' problem Smile

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

That's unfortunate. If you want someone to scoop bits up and feed Linus,
I'm happy to volunteer for the task, as long as you're still willing
to eyeball serial diffs until I get up to speed.

Dave
-
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/

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

On Thu, 21 Sep 2006 19:25:19 -0400
Trond Myklebust <trond.myklebust RemoveThis @fys.uio.no> wrote:

> On Wed, 2006-09-20 at 20:39 -0700, Andrew Morton wrote:
> > On Wed, 20 Sep 2006 17:55:33 -0400
> > Trond Myklebust <trond.myklebust RemoveThis @fys.uio.no> 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?
>

Yes, I am. Mainline broke.
-
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/

Alan Cox · External Since: Sep 11, 2004 Posts: 1608

Ar Gwe, 2006-09-22 am 11:48 -0400, ysgrifennodd Dave Jones:
> That's unfortunate. If you want someone to scoop bits up and feed Linus,
> I'm happy to volunteer for the task, as long as you're still willing
> to eyeball serial diffs until I get up to speed.

I'll give you a hand with that, I've got to do some work in that area
anyway for the arbitary speed support.

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

Dave Jones · External Since: Mar 15, 2005 Posts: 720

On Fri, Sep 22, 2006 at 05:24:01PM +0100, Alan Cox wrote:
> Ar Gwe, 2006-09-22 am 11:48 -0400, ysgrifennodd Dave Jones:
> > That's unfortunate. If you want someone to scoop bits up and feed Linus,
> > I'm happy to volunteer for the task, as long as you're still willing
> > to eyeball serial diffs until I get up to speed.
>
> I'll give you a hand with that, I've got to do some work in that area
> anyway for the arbitary speed support.

Cool, sounds good to me. Russell?

Dave
-
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 Fri, 22 Sep 2006 15:42:33 +0100
Christoph Hellwig <hch DeleteThis @infradead.org> wrote:

> > ecryptfs-versioning-fixes-tidy.patch
> >
> > Will fold into a single patch and will then merge.
>
> Please add a
>
> Not-Acked-By: Christoph Hellwig <hch DeleteThis @lst.de>
>
> here as you don't seem to listen to any of the comments I had against
> the current state and I want this clearly documented.

I thought everything got addressed, apart from

- please split all the generic stackable filesystem passthorugh routines
into a separated stackfs layer, in a few files in fs/stackfs/ that
you depend on. They'll get _GPL exported to all possible stackable
filesystem. They'll need their own store underlying object helpers,
but that can be made to work by embedding the generic stackfs data
as first thing in the ecryptfs object.

which seemed rather a lot to ask.
-
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/

Linus Torvalds · External Since: Jan 12, 2005 Posts: 517

On Fri, 22 Sep 2006, Dave Jones wrote:
>
> Hmm. Some trees do seem to get pulled more often than others.
> Linus, is there a upper limit on the number of times you want
> to see pull requests? It strikes me as odd, so I'm wondering
> if there are some crossed wires here.

I personally prefer to not see _too_ many pull requests, since that to me
indicates that people don't take advantage of the distributed nature of
git, and don't let things "simmer" in their own tree for a while.

[ Side note, just to explain how I personally work: getting too many
requests about the same tree confuses and sometimes irritates me, since
I tend to "batch up" my work. For example, for the last couple of days,
I've been mostly in "discussion mode", and have been talking about
licenses and workflow issues etc.

And then at some point (probably later today) I decide to go into "merge
mode" and go back to old mails I ignored and start applying them and
pulling from other peoples git trees. And so if my "mode switching" has
a longer latency than the "please pull" frequency, I end up seeing two
requests for the same tree during the same "merge mode" thing, which
just means that when I look at the older one, it no longer matches what
is in the tree I'm pulling from.

I've long done this "batching" thing - it's something I eventually
worked out with my patch-flow with Alan, and that I think we've
perfected with Andrew (probably largely _because_ we worked it out with
Alan after a certain amount of friction Wink

.

I personally at least _feel_ like I'm more efficient when I can just
completely switch gears, rather than having a constant trickle of
different things happening.

Hopefully that explains the other side of why I prefer to not get two
pull requests for the same tree within days of each other - I may simply
not even have gotten _around_ to the first one yet, and then the second
one just irritates me. ]

For example, I think that project maintainers should to some degree just
talk about their _own_ trees, rather than try to get their changes into my
tree, and then point to that. One of the big ideas in distribution (at
least to me) is that I'm _not_ supposed to be the "one and only", and I
think we should aim for a situation where people who develop in certain
specific areas can interact directly with the people who are testing the
results, so that by the time I get a "please pull" request, most of the
bulk of the work should hopefully already have gone through a cycle.

And all this is not even really git-centric. It's obviously what Andrew
does with the -mm tree too - havign a certain amount of "latency" is good.

That said, the "release early, release often" thing still holds, and
letting things wait _too_ long just means that the _only_ people who test
it is some very specific group, and you may not see the problems that a
bigger environment would see.

So it's a balance between "by the time you send it on, it should hopefully
have had a day or two of testing" _and_ a "by the time you send it on you
shouldn't have forgotten the issues and think it's old and all done".

I would _personally_ judge that if you need to push me the same tree more
than once a week (not counting mistakes and brown-paper bugs that
obviously happen - I'm saying "in general" here), there's likely something
strange going on.

But at the same time, please do keep in mind thatr it's partly just a
matter of taste, and it's also very much a matter of work habits (and
about how active the tree is). Some people tend to work in certain ways.

I think rmk keeps his git trees in a private location (and I think it's
because the kernel.org maintainers asked us to not mirror things out
publicly if we didn't need to), so I think part of the reason the ARM
trees get pushed out more actively is simply because Russell has used my
tree as a "distribution point".

I don't think that's necessarily great, and there's been some friction
over it ("people are waiting for this"), but it's not been a _huge_
problem either, so I just lump it in the "different people, different ways
to work" pile..

Linus
-
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: 1465

NOTE: Your mailer generates bogus Mail-Followup-To headers, and you
snipped rmk from the To/CC.

Dave Jones wrote:
> Hmm. Some trees do seem to get pulled more often than others.
> Linus, is there a upper limit on the number of times you want
> to see pull requests? It strikes me as odd, so I'm wondering
> if there are some crossed wires here.

Not speaking for Linus, but in general it seems like the more pull
requests you send (within reason), the more pulls that occur. Russell
and DaveM certainly seem to send frequent, successful pull requests.

> Has Andrew commented on why this is proving to be more of a problem?
> I've done regular rebases of cpufreq/agpgart (admittedly, they don't
> reject hardly ever unless Len has ACPI bits touching cpufreq) without
> causing too much headache.

Rebasing _inevitably_ causes more headaches than a simple tree update,
for any downstream consumer of your tree(s). It is best to avoid wanton
rebasing.

Think about it: if someone is pulling and merging your tree, all of a
sudden, without warning, the entire hash history is rewritten. So
rather than a Nice and Friendly minor update, the next time they pull
your stuff, the downstream user is forced to suffer through either (a) a
painful merge, or (b) back out your last tree (ugh!) and redo things
from scratch.

Rebasing might make a pretty history, but it is _not_ fun for random
consumers of your trees. It basically punishes people for following
your tree -- not something you want to do.

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/

Michael Halcrow · External Since: May 15, 2006 Posts: 89

On Fri, Sep 22, 2006 at 09:03:37AM -0700, Andrew Morton wrote:
> On Fri, 22 Sep 2006 15:42:33 +0100
> Christoph Hellwig <hch.RemoveThis@infradead.org> wrote:
>
> > > ecryptfs-versioning-fixes-tidy.patch
> > >
> > > Will fold into a single patch and will then merge.
> >
> > Please add a
> >
> > Not-Acked-By: Christoph Hellwig <hch.RemoveThis@lst.de>
> >
> > here as you don't seem to listen to any of the comments I had
> > against the current state and I want this clearly documented.
>
> I thought everything got addressed, apart from
>
> - please split all the generic stackable filesystem passthorugh routines
> into a separated stackfs layer, in a few files in fs/stackfs/ that
> you depend on. They'll get _GPL exported to all possible stackable
> filesystem. They'll need their own store underlying object helpers,
> but that can be made to work by embedding the generic stackfs data
> as first thing in the ecryptfs object.
>
> which seemed rather a lot to ask.

A common framework that would be useful for all potential stackable
filesystems is indeed a major project in and of itself, and such a
thing right now would be premature. We need to see how code for other
stackable filesystems will look once it is actually in the
kernel. There is core behavior that differs between eCryptfs and
Unionfs -- for instance, how inodes are referenced. eCryptfs, in its
current form, can do just fine with referencing the internal inode
struct pointer, whereas Unionfs implements persistent inodes. Then
there are issues with readdir/filldir semantics, wherein Unionfs needs
a mechanism to implement whiteout operations. eCryptfs just has a
simple one-to-one VFS layer mapping, while Unionfs has to merge
several VFS mounts under it. The core *_info data structure diverge
quite a bit between the two. Right now, eCryptfs and Unionfs can get
by with a page-to-page mapping between the upper and lower files, but
that would not necessarily be the case for a compressing stacked
layer; the common framework would have to take that into
consideration.

Stacked filesystem authors are certainly interested in addressing
these sorts of issues, but an iterative strategy for solving them is
the most reasonable approach. The first step is to get at least two
stacked filesystems into the kernel (eCryptfs and Unionfs) and then
follow up with a series of patches to extract the common functionality
once we see somewhat finalized code bases for both.

Mike
-
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/

Dave Jones · External Since: Mar 15, 2005 Posts: 720

On Fri, Sep 22, 2006 at 12:29:21PM -0400, Jeff Garzik wrote:
>
> NOTE: Your mailer generates bogus Mail-Followup-To headers, and you
> snipped rmk from the To/CC.

Actually, my mailer just respected the Mail-Followup-To: that
rmk set in his mail that I replied to. Nothing to see here.

Dave
-
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/

Dave Jones · External Since: Mar 15, 2005 Posts: 720

On Fri, Sep 22, 2006 at 12:29:21PM -0400, Jeff Garzik wrote:
>
> NOTE: Your mailer generates bogus Mail-Followup-To headers, and you
> snipped rmk from the To/CC.

Hmm, curious. I'll file a bug.

> > Has Andrew commented on why this is proving to be more of a problem?
> > I've done regular rebases of cpufreq/agpgart (admittedly, they don't
> > reject hardly ever unless Len has ACPI bits touching cpufreq) without
> > causing too much headache.
>
> Rebasing _inevitably_ causes more headaches than a simple tree update,
> for any downstream consumer of your tree(s). It is best to avoid wanton
> rebasing.

Sorry, terminology confusion. I rarely throw away a tree and start afresh,
I meant of course just updating to linus' latest. This may explain the
my lack of understanding over Russell's issues.

Dave
-
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 Fri, 22 Sep 2006, Martin Bligh wrote:

> However, whatever you do, meeting (2) is rather hard - it's a damned
> sight simpler to stuff it all in ZONE_DMA because that's the end of
> the fallback list.

That used to be the case. If you switch ZONE_DMA off (like possible in mm)
then ZONE_NORMAL is the end of the fallback. I think we basically want
the same thing and get to the same result.

-
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

Christoph Lameter wrote:
> 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.

Given that the definition of ZONE_DMA is, I think we agree, nonsensical
in generic code anyway, whatever we do is going to be a pain.

I disagree that what you're doing is consistent with established
usage, see PPC64 for example, which I assumed you'd changed to be
consistent with what you're doing ... but it seems you haven't.

Your definition is one way of interpreting the current setup. It even
makes some sort of sense, I'll admit. However, there are other
definitions that make perfect sense too, which just goes to show that
the concept of ZONE_DMA is just a frigging inconsistent mess to start
with.

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

That is one possible way of defining it, but seeing as there is no
agreed to, documented definition, it's hard to tell whether this trumps
such other defined constants such as "GFP_DMA means gives me memory from
ZONE_DMA", which you're now violating.

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

It seems odd that PPC64 has worked fine this way for a long time then?

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

The last sentence in this is your opinion, not an agreed-to definition.

Look, whatever we do is not going to be wholly clean, as the definitons
and requirements we start from are loose, inconsistent and somewhat
contradictary on occasion. So what we are left with is picking something
that is:

1. As consistent as possible across architectures.
2. As simple as possible.

If you can agree with the other arch maintainers (eg PPC64) that
stuffing it all in ZONE_NORMAL is somehow better than ZONE_DMA, then
maybe we can meet (1).

However, whatever you do, meeting (2) is rather hard - it's a damned
sight simpler to stuff it all in ZONE_DMA because that's the end of
the fallback list.

M.

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

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

On Fri, 22 Sep 2006 11:10:01 +0100 David Woodhouse wrote:

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

That was originally posted as a patch to -mm, where that field
has been changed to (unsigned?) int. Maybe it should be part
of Jens's block patches, since that is what changes the field
size.

---
~~Randy
-
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/

Jesse Barnes · External Since: Aug 25, 2006 Posts: 70

On Friday, September 22, 2006 10:21 am, Jesse Barnes wrote:
> If you have a decent enough IOMMU both or either could cover all of
> memory. In the case of an Altix, the IOMMU is 32 bit capable, so it
> would make sense for ZONE_DMA32 to contain all of memory...
>
> But anyway, I agree with your broader point that we really need a
> different allocator for this stuff. It has to be arch specific in some
> way though, so we can take into account the advantages IOMMUs provide.
> I think jejb said he'd come up with a sample implementation a couple of
> years ago... Smile

>
> From a portability and definition perspective, I'd contend that ZONE_DMA
> and ZONE_DMA32 are both broken. Only ZONE_NORMAL and ZONE_HIGHMEM have
> sane definitions it seems.

Ok and right after I sent this my brain returned from vacation and I
remembered jejb's DMA allocation API. It's powerful enough to cover most
driver use cases I think (users of GFP_DMA should probably be converted),
but for example block layer bounce buffering might need a different
interface as I see you've proposed in another mail.

Hm... s390 driver seem to like GFP_DMA a lot... and there are a few
remaining uses in drivers/scsi... and then of course there are the OSS
drivers...

Jesse
-
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/

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

On Fri, 22 Sep 2006, Jesse Barnes wrote:

> Ok and right after I sent this my brain returned from vacation and I
> remembered jejb's DMA allocation API. It's powerful enough to cover most
> driver use cases I think (users of GFP_DMA should probably be converted),
> but for example block layer bounce buffering might need a different
> interface as I see you've proposed in another mail.

Could you dig that out and give us some refs or even better port that
thing to a current mm tree?
-
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/