From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2008-07-09 07:34:52
I've pushed some updates to my version of powerpc.git.
The tree itself is at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
It contains 3 branches:
- merge : this is for merging with the current stable and doesn't
currently contain anything interesting
- master : this is our current "powerpc.git" tree, it may contain
various experimental stuff that may or may not go upstream
or may contain dependent patches that we rely on but that
are to be merged via some other tree.
- next : this is the candidate stuff for linux-next and the next
merge window
(Andrew, you -may- want to pull that instead of paulus one until
he's back from vacation).
Until today, master and next pointed to the same commit, which was
the same as paulus master and powerpc-next branches. Tonight, I've
pushed some patches to master that I intend to have in next, but
I'd like to let them sit in master for a couple of days to make sure
nothing is badly broken mostly and make sure I didn't screw up in
my various patch monkeying operations.
Here are the newly applied patches:
Benjamin Herrenschmidt (1):
powerpc: Use new printk extension %pS to print symbols on oops
Dave Kleikamp (5):
mm: Allow architectures to define additional protection bits
powerpc/mm: Define flags for Strong Access Ordering
powerpc/mm: Add SAO Feature bit to the cputable
powerpc/mm: Add Strong Access Ordering support
powerpc/mm: Don't clear _PAGE_COHERENT when _PAGE_SAO is set
Geoff Levand (1):
powerpc/ps3: Quiet system bus match output
Grant Erickson (1):
ibm_newemac: Parameterize EMAC Multicast Match Handling
Jeremy Kerr (4):
powerpc/spufs: avoid magic numbers for mapping sizes
powerpc/spufs: allow spufs files to specify sizes
powerpc/spufs: add sizes for context files
powerpc/spufs: only add ".ctx" file with "debug" mount option
Luke Browning (2):
powerpc/spufs: provide context debug file
powerpc/spufs: don't extend time time slice if context is not in spu_run
Mark Nelson (4):
powerpc/dma: Add struct iommu_table argument to iommu_map_sg()
powerpc/dma: implement new dma_*map*_attrs() interfaces
powerpc/cell: cell_dma_dev_setup_iommu() return the iommu table
powerpc: move device_to_mask() to dma-mapping.h
Maxim Shchetynin (1):
powerpc/spufs: add atomic busy_spus counter to struct cbe_spu_info
Michael Neuling (2):
powerpc: fix swapcontext backwards compat. with VSX ucontext changes
powerpc: remove unused variable in emulate_fp_pair
Mike Mason (1):
powerpc/eeh: PERR/SERR bit settings during EEH device recovery
Paul Gortmaker (1):
powerpc/ibmebus: more meaningful variable name
Srinivasa Ds (1):
powerpc: Implement task_pt_regs() accessor
From: Kumar Gala <hidden> Date: 2008-07-09 12:58:48
On Jul 9, 2008, at 2:34 AM, Benjamin Herrenschmidt wrote:
I've pushed some updates to my version of powerpc.git.
The tree itself is at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
It contains 3 branches:
- merge : this is for merging with the current stable and doesn't
currently contain anything interesting
- master : this is our current "powerpc.git" tree, it may contain
various experimental stuff that may or may not go upstream
or may contain dependent patches that we rely on but that
are to be merged via some other tree.
- next : this is the candidate stuff for linux-next and the next
merge window
(Andrew, you -may- want to pull that instead of paulus one until
he's back from vacation).
Until today, master and next pointed to the same commit, which was
the same as paulus master and powerpc-next branches. Tonight, I've
pushed some patches to master that I intend to have in next, but
I'd like to let them sit in master for a couple of days to make sure
nothing is badly broken mostly and make sure I didn't screw up in
my various patch monkeying operations.
What is your intent with the 'master' branch? I hope you do NOT plan
on ever rebasing it. I assume if a patch gets into master and we drop
it you'll do a git-revert of it?
- k
From: Stephen Rothwell <hidden> Date: 2008-07-09 16:08:42
Kumar,
On Wed, 9 Jul 2008 07:58:38 -0500 Kumar Gala [off-list ref] wrote:
What is your intent with the 'master' branch? I hope you do NOT plan
on ever rebasing it. I assume if a patch gets into master and we drop
it you'll do a git-revert of it?
"Ever" is such a strong word. Even Paul on occasion rebased his master
branch. I see no reason why Ben could not run his master (or maybe
better named "test") branch as a place that patches come and go and his
"next" branch as something that never (or very rarely) gets rebased with
commits progressing from master (test) to next when he is satisfied with
them. People should then base further work in the "next" branch.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
From: Grant Likely <hidden> Date: 2008-07-09 16:20:12
On Thu, Jul 10, 2008 at 02:08:32AM +1000, Stephen Rothwell wrote:
Kumar,
On Wed, 9 Jul 2008 07:58:38 -0500 Kumar Gala [off-list ref] wrote:
quoted
What is your intent with the 'master' branch? I hope you do NOT plan
on ever rebasing it. I assume if a patch gets into master and we drop
it you'll do a git-revert of it?
"Ever" is such a strong word. Even Paul on occasion rebased his master
branch. I see no reason why Ben could not run his master (or maybe
better named "test") branch as a place that patches come and go and his
"next" branch as something that never (or very rarely) gets rebased with
commits progressing from master (test) to next when he is satisfied with
them. People should then base further work in the "next" branch.
I was under the impression that there was some consensus that -next
branches should be used for unstable experiments. Am I mistaken?
g.
On Wed, 2008-07-09 at 10:20 -0600, Grant Likely wrote:
On Thu, Jul 10, 2008 at 02:08:32AM +1000, Stephen Rothwell wrote:
quoted
Kumar,
On Wed, 9 Jul 2008 07:58:38 -0500 Kumar Gala [off-list ref] wrote:
quoted
What is your intent with the 'master' branch? I hope you do NOT plan
on ever rebasing it. I assume if a patch gets into master and we drop
it you'll do a git-revert of it?
"Ever" is such a strong word. Even Paul on occasion rebased his master
branch. I see no reason why Ben could not run his master (or maybe
better named "test") branch as a place that patches come and go and his
"next" branch as something that never (or very rarely) gets rebased with
commits progressing from master (test) to next when he is satisfied with
them. People should then base further work in the "next" branch.
I was under the impression that there was some consensus that -next
branches should be used for unstable experiments. Am I mistaken?
Yes, you are. It's slightly confusing. -next branches are for things
decidedly going into the "next" release of the kernel. If they are
unstable, they aren't really proven to be ready then.
josh
From: Kumar Gala <hidden> Date: 2008-07-09 17:03:53
On Jul 9, 2008, at 11:31 AM, Josh Boyer wrote:
On Wed, 2008-07-09 at 10:20 -0600, Grant Likely wrote:
quoted
On Thu, Jul 10, 2008 at 02:08:32AM +1000, Stephen Rothwell wrote:
quoted
Kumar,
On Wed, 9 Jul 2008 07:58:38 -0500 Kumar Gala <galak@kernel.crashing.org
quoted
wrote:
What is your intent with the 'master' branch? I hope you do NOT
plan
on ever rebasing it. I assume if a patch gets into master and we
drop
it you'll do a git-revert of it?
"Ever" is such a strong word. Even Paul on occasion rebased his
master
branch. I see no reason why Ben could not run his master (or maybe
better named "test") branch as a place that patches come and go
and his
"next" branch as something that never (or very rarely) gets
rebased with
commits progressing from master (test) to next when he is
satisfied with
them. People should then base further work in the "next" branch.
I was under the impression that there was some consensus that -next
branches should be used for unstable experiments. Am I mistaken?
Yes, you are. It's slightly confusing. -next branches are for
things
decidedly going into the "next" release of the kernel. If they are
unstable, they aren't really proven to be ready then.
Did, GregKH start up a tree for code not quite ready ( -staging).
I think master and -next should not be rebased (if it can be
avoided). and -staging can be.
- k
On Wed, 9 Jul 2008 11:47:45 -0500
Kumar Gala [off-list ref] wrote:
On Jul 9, 2008, at 11:31 AM, Josh Boyer wrote:
quoted
On Wed, 2008-07-09 at 10:20 -0600, Grant Likely wrote:
quoted
On Thu, Jul 10, 2008 at 02:08:32AM +1000, Stephen Rothwell wrote:
quoted
Kumar,
On Wed, 9 Jul 2008 07:58:38 -0500 Kumar Gala <galak@kernel.crashing.org
quoted
wrote:
What is your intent with the 'master' branch? I hope you do NOT
plan
on ever rebasing it. I assume if a patch gets into master and we
drop
it you'll do a git-revert of it?
"Ever" is such a strong word. Even Paul on occasion rebased his
master
branch. I see no reason why Ben could not run his master (or maybe
better named "test") branch as a place that patches come and go
and his
"next" branch as something that never (or very rarely) gets
rebased with
commits progressing from master (test) to next when he is
satisfied with
them. People should then base further work in the "next" branch.
I was under the impression that there was some consensus that -next
branches should be used for unstable experiments. Am I mistaken?
Yes, you are. It's slightly confusing. -next branches are for
things
decidedly going into the "next" release of the kernel. If they are
unstable, they aren't really proven to be ready then.
Did, GregKH start up a tree for code not quite ready ( -staging).
Yes. The proliferation of "trees" is getting to be a bit ridiculous.
We have Linus, -next, -mm, -staging, plus all the subsystem variants of
those.
The answer to "What tree do I develop against" _should_ be -next, but
sometimes that isn't the case and finding the answer isn't getting
easier.
josh
From: Stephen Rothwell <hidden> Date: 2008-07-09 17:25:48
Hi Kumar,
On Wed, 9 Jul 2008 11:47:45 -0500 Kumar Gala [off-list ref] wrote:
Did, GregKH start up a tree for code not quite ready ( -staging).
Greg's staging tree is for whole drivers etc not in the kernel yet that
need work to get there.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
From: Stephen Rothwell <hidden> Date: 2008-07-09 17:23:54
Hi Grant,
On Wed, 9 Jul 2008 10:20:08 -0600 Grant Likely [off-list ref] wrote:
I was under the impression that there was some consensus that -next
branches should be used for unstable experiments. Am I mistaken?
Completely. Anything that will end up in linux-next must be posted,
reviewed, unit tested and intended for the next merge window. i.e. you
must have basically finished with it (except for inter-subsystem merge
problems and bugs, or course).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
From: Grant Likely <hidden> Date: 2008-07-09 17:30:26
On Thu, Jul 10, 2008 at 03:23:46AM +1000, Stephen Rothwell wrote:
Hi Grant,
On Wed, 9 Jul 2008 10:20:08 -0600 Grant Likely [off-list ref] wrote:
quoted
I was under the impression that there was some consensus that -next
branches should be used for unstable experiments. Am I mistaken?
Completely. Anything that will end up in linux-next must be posted,
reviewed, unit tested and intended for the next merge window. i.e. you
must have basically finished with it (except for inter-subsystem merge
problems and bugs, or course).
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2008-07-12 03:32:10
What is your intent with the 'master' branch? I hope you do NOT plan
on ever rebasing it. I assume if a patch gets into master and we drop
it you'll do a git-revert of it?
I'll try as much as possible. But I'll keep the option open. "next" is
the one that should never be rebased I'd say.
Ben.
From: Grant Likely <hidden> Date: 2008-07-12 03:35:30
On Sat, Jul 12, 2008 at 01:30:58PM +1000, Benjamin Herrenschmidt wrote:
quoted
What is your intent with the 'master' branch? I hope you do NOT plan
on ever rebasing it. I assume if a patch gets into master and we drop
it you'll do a git-revert of it?
I'll try as much as possible. But I'll keep the option open. "next" is
the one that should never be rebased I'd say.
I'm cool with that. As long as I've got something stable to commit on
top of. :-)
g.
On Wed, 09 Jul 2008 17:34:41 +1000
Benjamin Herrenschmidt [off-list ref] wrote:
I've pushed some updates to my version of powerpc.git.
=20
The tree itself is at:
=20
=EF=BB=BF git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
=20
It contains 3 branches:
=20
- merge : this is for merging with the current stable and doesn't
currently contain anything interesting
=20
- master : this is our current "powerpc.git" tree, it may contain
various experimental stuff that may or may not go upstream
or may contain dependent patches that we rely on but that
are to be merged via some other tree.
=20
- next : this is the candidate stuff for linux-next and the next
merge window
=20
(Andrew, you -may- want to pull that instead of paulus one until
he's back from vacation).
=20
Until today, master and next pointed to the same commit, which was
the same as paulus master and powerpc-next branches. Tonight, I've
pushed some patches to master that I intend to have in next, but
I'd like to let them sit in master for a couple of days to make sure
nothing is badly broken mostly and make sure I didn't screw up in
my various patch monkeying operations.
One thing to point out is that if you decide to only select a few of
those patches, you'll need to cherry-pick them into your next branch
(or rebase). That means that when you pull from Linus into your master
branch during/after the merge window, you'll get all kinds of funny
merge commits.
If you want to use your master branch as a place for experimental
stuff, that's fine by me. But you'll want to keep next separate from
it so it's as "clean" as possible for those trying to track what is
definitely going into the next release.
If it were up to me (which it's not), I would have master just track
Linus, next track what's going into the next release, and "bleeding" or
"experimental" track stuff that isn't fully vetted yet. I might start
doing that with my tree in the very near future.
Also, Paul is pretty good about not rebasing his branches when at all
possible, and I suspect that's why his master and next were often the
same. It makes life lots easier for the sub-maintainers and anyone
trying to track against the tree. I humbly beg you to keep that going.
josh
From: Kumar Gala <hidden> Date: 2008-07-09 13:42:45
On Jul 9, 2008, at 8:18 AM, Josh Boyer wrote:
On Wed, 09 Jul 2008 17:34:41 +1000
Benjamin Herrenschmidt [off-list ref] wrote:
quoted
I've pushed some updates to my version of powerpc.git.
The tree itself is at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
It contains 3 branches:
- merge : this is for merging with the current stable and doesn't
currently contain anything interesting
- master : this is our current "powerpc.git" tree, it may contain
various experimental stuff that may or may not go
upstream
or may contain dependent patches that we rely on but that
are to be merged via some other tree.
- next : this is the candidate stuff for linux-next and the next
merge window
(Andrew, you -may- want to pull that instead of paulus one until
he's back from vacation).
Until today, master and next pointed to the same commit, which was
the same as paulus master and powerpc-next branches. Tonight, I've
pushed some patches to master that I intend to have in next, but
I'd like to let them sit in master for a couple of days to make sure
nothing is badly broken mostly and make sure I didn't screw up in
my various patch monkeying operations.
One thing to point out is that if you decide to only select a few of
those patches, you'll need to cherry-pick them into your next branch
(or rebase). That means that when you pull from Linus into your master
branch during/after the merge window, you'll get all kinds of funny
merge commits.
If you want to use your master branch as a place for experimental
stuff, that's fine by me. But you'll want to keep next separate from
it so it's as "clean" as possible for those trying to track what is
definitely going into the next release.
If it were up to me (which it's not), I would have master just track
Linus, next track what's going into the next release, and "bleeding"
or
"experimental" track stuff that isn't fully vetted yet. I might start
doing that with my tree in the very near future.
I do something similar, but my master is a merge of linus and my next
branch, which is roughly what I think paul did.
Also, Paul is pretty good about not rebasing his branches when at all
possible, and I suspect that's why his master and next were often the
same. It makes life lots easier for the sub-maintainers and anyone
trying to track against the tree. I humbly beg you to keep that
going.
I agree and I'm sure linus will tell you how evil it is to rebase as a
maintainer.
- k
From: Grant Likely <hidden> Date: 2008-07-09 14:38:11
On Wed, Jul 09, 2008 at 08:40:21AM -0500, Kumar Gala wrote:
On Jul 9, 2008, at 8:18 AM, Josh Boyer wrote:
quoted
On Wed, 09 Jul 2008 17:34:41 +1000
Benjamin Herrenschmidt [off-list ref] wrote:
Also, Paul is pretty good about not rebasing his branches when at all
possible, and I suspect that's why his master and next were often the
same. It makes life lots easier for the sub-maintainers and anyone
trying to track against the tree. I humbly beg you to keep that
going.
I agree and I'm sure linus will tell you how evil it is to rebase as a
maintainer.
Add my voice to the chorus. Rebasing a branch that I commit on top of
really messes up the workflow.
g.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2008-07-12 03:41:20
On Wed, 2008-07-09 at 09:18 -0400, Josh Boyer wrote:
If you want to use your master branch as a place for experimental
stuff, that's fine by me. But you'll want to keep next separate from
it so it's as "clean" as possible for those trying to track what is
definitely going into the next release.
Yes. The idea is that "next" stays clean.
If it were up to me (which it's not), I would have master just track
Linus, next track what's going into the next release, and "bleeding"
or "experimental" track stuff that isn't fully vetted yet. I might
start doing that with my tree in the very near future.
Why keeping a branch to track linus in my public tree ? I have plenty of
these locally :-)
Also, Paul is pretty good about not rebasing his branches when at all
possible, and I suspect that's why his master and next were often the
same. It makes life lots easier for the sub-maintainers and anyone
trying to track against the tree. I humbly beg you to keep that
going.
Yes. I intend to stay on that line, but as I'm new to the job, mistake
are more likely to happen.
Cheers,
Ben.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2008-07-14 05:32:48
On Wed, 2008-07-09 at 17:34 +1000, Benjamin Herrenschmidt wrote:
It contains 3 branches:
- merge : this is for merging with the current stable and doesn't
currently contain anything interesting
- master : this is our current "powerpc.git" tree, it may contain
various experimental stuff that may or may not go upstream
or may contain dependent patches that we rely on but that
are to be merged via some other tree.
- next : this is the candidate stuff for linux-next and the next
merge window
-next and -merge are now both to the same level, which is the same
as I pushed last week plus a merge with 2.6.26 to resolve a conflict.
I'll start putting new stuff in tomorrow if all goes well.
Cheers,
Ben.