From: Wolfgang Denk <hidden> Date: 2004-03-23 16:44:36
Dear Tolunay,
in message [off-list ref] you wrote:
quoted
A more up-to-date implementation seems to be in the
"linuxppc-2.4" tree. Are there some open issues or known
problems? I realized that the L2 cache has been disabled
recently:
Regarding penguinppc.org BitKeeper trees, I was told that
linuxppc_2_4_devel tree is now dead and all commits are done against
linuxppc-2.4. Perhaps maintainers can clarify that in more detail. My
405GP snapshot is coming from linuxppc-2.4.
Officially linuxppc-2.4 is the official tree ;-) But then it seems
that there is still a lot of difference between linuxppc_2_4_devel
and linuxppc-2.4, and I think you can find new features in both trees
that are not (yet?) present in the other tree.
There is also another linuxppc_2_4_devel tree maintained by DENX. I don't
I guess Wolfgang Grandegger is aware of this. His other email address
is [off-list ref] :-)
But there are so many other trees. There is things like the ameslab
tree or the Linux-Tiny Tree or CELinux source tree or ...
know the sync state between these two trees. It is my understanding that
DENX tree has some fixes that might not be in the BK trees.
Our linuxppc_2_4_devel tree is in sync with the BK linuxppc_2_4_devel
tree. But there is lots of additional stuff in out tree that never
made it into the "official trees". So many of our contributions were
rejected or delayed or ignored that I finally gave up.
IMHO, the community would be best served by single set of sources...
Indeed. But I think this is as likely as a world without war :-(
I would be perfectly happy if there was some plan or roadmap or just
a description of the current state which says which tree is in which
state, if it is maintained and by whom, and how long it will be
maintained, and when or why or by whom it might be declared as "dead"
(as happened with the linuxppc_2_4_devel tree), or if anybody is
actually taking care of the known problems, and when, etc.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
Inside every old person is a young person wondering what happened.
- Terry Pratchett, _Moving Pictures_
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Wolfgang,
In addition to this nice tree discussion, I've a question:
from what 'official ppc' tree do patches eventually get into the
official linux kernel tree(s) at kernel.org?
only linuxppc-2.4? Or all?
thanks,
Jaap-Jan
On Tue, 2004-03-23 at 17:44, Wolfgang Denk wrote:
Dear Tolunay,
in message [off-list ref] you wrote:
quoted
quoted
A more up-to-date implementation seems to be in the
"linuxppc-2.4" tree. Are there some open issues or known
problems? I realized that the L2 cache has been disabled
recently:
Regarding penguinppc.org BitKeeper trees, I was told that
linuxppc_2_4_devel tree is now dead and all commits are done against
linuxppc-2.4. Perhaps maintainers can clarify that in more detail. My
405GP snapshot is coming from linuxppc-2.4.
Officially linuxppc-2.4 is the official tree ;-) But then it seems
that there is still a lot of difference between linuxppc_2_4_devel
and linuxppc-2.4, and I think you can find new features in both trees
that are not (yet?) present in the other tree.
quoted
There is also another linuxppc_2_4_devel tree maintained by DENX. I don't
I guess Wolfgang Grandegger is aware of this. His other email address
is [off-list ref] :-)
But there are so many other trees. There is things like the ameslab
tree or the Linux-Tiny Tree or CELinux source tree or ...
quoted
know the sync state between these two trees. It is my understanding that
DENX tree has some fixes that might not be in the BK trees.
Our linuxppc_2_4_devel tree is in sync with the BK linuxppc_2_4_devel
tree. But there is lots of additional stuff in out tree that never
made it into the "official trees". So many of our contributions were
rejected or delayed or ignored that I finally gave up.
quoted
IMHO, the community would be best served by single set of sources...
Indeed. But I think this is as likely as a world without war :-(
I would be perfectly happy if there was some plan or roadmap or just
a description of the current state which says which tree is in which
state, if it is maintained and by whom, and how long it will be
maintained, and when or why or by whom it might be declared as "dead"
(as happened with the linuxppc_2_4_devel tree), or if anybody is
actually taking care of the known problems, and when, etc.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
Inside every old person is a young person wondering what happened.
- Terry Pratchett, _Moving Pictures_
--
J.G.J. Boor Anton Philipsweg 1
Software Engineer 1223 KZ Hilversum
AimSys bv tel. +31 35 689 1941
Postbus 2194, 1200 CD Hilversum mailto:jjboor@aimsys.nl
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Dan Malek <hidden> Date: 2004-03-23 18:24:11
Jaap-Jan Boor wrote:
from what 'official ppc' tree do patches eventually get into the
official linux kernel tree(s) at kernel.org?
only linuxppc-2.4? Or all?
It seems to be a circuitous route that I don't even understand
anymore. Sometime stuff I check in gets there, sometimes not. :-)
http://penguinppc.org/dev/kernel.shtml tries to explain it.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
this states you should build/submit patches against kernel.org's
trees, which is quite different from linuxppc-2.[45], which is probably
Tom Rini's checkout of kernel.org's tree with all ppc patches.
Or is it?
thanks for your reply,
Jaap-Jan
this states you should build/submit patches against kernel.org's
trees, which is quite different from linuxppc-2.[45], which is probably
Tom Rini's checkout of kernel.org's tree with all ppc patches.
Or is it?
linuxppc-2.[45] are children of the linux-2.[45] trees, and contain
stuff that's not quite ready to go out, _but_will_be_soon_ or has been
put in a tree for Linus/Marcelo, but they haven't pulled yet.
--
Tom Rini
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
It seems to be a circuitous route that I don't even understand
anymore. Sometime stuff I check in gets there, sometimes not. :-)
and you have never found out the conditions when something
get's in (only when submitted at friday the 13th or something?)
Um, yeah. I'm hoping 2.6 will be different from 2.4 in that regard. :)
ok!
linuxppc-2.[45] are children of the linux-2.[45] trees, and contain
stuff that's not quite ready to go out, _but_will_be_soon_ or has been
put in a tree for Linus/Marcelo, but they haven't pulled yet.
ok thanks (and linuxppc-2.5 should be used to get something into 2.6?)
Jaap-Jan
From: Paul Mackerras <hidden> Date: 2004-03-25 12:12:16
Jaap-Jan Boor writes:
In addition to this nice tree discussion, I've a question:
from what 'official ppc' tree do patches eventually get into the
official linux kernel tree(s) at kernel.org?
only linuxppc-2.4? Or all?
Well, the thing to understand is that there is no automatic,
effortless way that code goes into the kernel.org trees. Every change
that goes in involves somebody putting together a patch against the
current state of the official kernel.org trees, together with a
description of what is being changed and why it is being changed, and
sending that to Marcelo Tosatti, Andrew Morton or Linus Torvalds.
BitKeeper can help to some extent with this, mainly by providing a way
for us to send Marcelo/Andrew/Linus a bunch of changes in one go. It
doesn't, however, provide any automatic way for changes to get from
the linuxppc-2.4 or linuxppc-2.5 trees into their trees. The reason
is that with BK, if you pull the changes from one tree into another
tree, you have to take all the changes in the first tree that aren't
in the second. You can't pick and choose which changesets get
transferred. Therefore, we don't ask Marcelo/Andrew/Linus to pull
from linuxppc-2.[45] into their trees. There is too much stuff in
there that isn't ready, or that I don't agree with, or that I just
don't understand.
I have taken on the role of ppc32 maintainer, part of which involves
sending changes to Marcelo/Andrew/Linus. However, doing that involves
work on my part to identify which changes in linuxppc-2.[45] are ready
to send, which changes logically go together, and I have to be able to
explain the change.
When it comes to things like the 8xx/82xx/85xx support, I rely on the
maintainers for that area -- Tom Rini and Dan Malek -- to do that work
of identifying sets of related changes that are suitable for inclusion
in the official trees, and packaging them up with an explanation so
that they can be sent upstream. (That can be done either with patches
or BK changesets; the amount of work required is pretty much the same
either way.)
Similarly, for the boot code I look to Tom and for the powermac
support I look to Ben Herrenschmidt. For the 4xx stuff there isn't
really a maintainer at the moment, unfortunately, except that Matt
Porter is looking after the 44x boards. I look after the classic
PowerPC core support -- exception handling, memory management, etc.,
and to some extent the 4xx core support, and the CHRP port.
What this boils down to is that for changes in these areas I expect
the maintainers for those areas to be packaging up the changes with
explanations, ready to go upstream. Anyone is of course welcome to
put together a patch + explanation and propose that it go upstream.
In such cases I would ask the maintainer for that area for his
opinion, or if there isn't a maintainer, I would ask the submitter if
they will commit to maintaining that area of the code. If they won't,
I would tend to drop the patch unless it is a simple, obviously
correct bugfix.
One problem we have at present is that there are a number of board
ports which don't appear to have a maintainer. Sometimes there are
people using those ports but noone taking responsibility for updating
it and keeping it working as things change elsewhere in the kernel.
Having a maintainer is a prerequisite for the board port to be sent
upstream.
I hope this clarifies things. If you want the kernel.org trees to
support your platform, then I suggest you put together the changes you
want to see as patches and send them to me and the maintainer for the
subarea. Make sure that the patch comes with a good explanation of
the change, and if you think the patch should go upstream, say so. If
possible make sure that the patch isn't too large. If it is large,
see if you can split it up into smaller patches, each of which
contains a logically related set of changes.
Regards,
Paul.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Paul,
Much thanks for your explanation, it clarifies a lot.
Jaap-Jan
On Thu, 25 Mar 2004, Paul Mackerras wrote:
Jaap-Jan Boor writes:
quoted
In addition to this nice tree discussion, I've a question:
from what 'official ppc' tree do patches eventually get into the
official linux kernel tree(s) at kernel.org?
only linuxppc-2.4? Or all?
Well, the thing to understand is that there is no automatic,
effortless way that code goes into the kernel.org trees. Every change
that goes in involves somebody putting together a patch against the
current state of the official kernel.org trees, together with a
description of what is being changed and why it is being changed, and
sending that to Marcelo Tosatti, Andrew Morton or Linus Torvalds.
BitKeeper can help to some extent with this, mainly by providing a way
for us to send Marcelo/Andrew/Linus a bunch of changes in one go. It
doesn't, however, provide any automatic way for changes to get from
the linuxppc-2.4 or linuxppc-2.5 trees into their trees. The reason
is that with BK, if you pull the changes from one tree into another
tree, you have to take all the changes in the first tree that aren't
in the second. You can't pick and choose which changesets get
transferred. Therefore, we don't ask Marcelo/Andrew/Linus to pull
from linuxppc-2.[45] into their trees. There is too much stuff in
there that isn't ready, or that I don't agree with, or that I just
don't understand.
I have taken on the role of ppc32 maintainer, part of which involves
sending changes to Marcelo/Andrew/Linus. However, doing that involves
work on my part to identify which changes in linuxppc-2.[45] are ready
to send, which changes logically go together, and I have to be able to
explain the change.
When it comes to things like the 8xx/82xx/85xx support, I rely on the
maintainers for that area -- Tom Rini and Dan Malek -- to do that work
of identifying sets of related changes that are suitable for inclusion
in the official trees, and packaging them up with an explanation so
that they can be sent upstream. (That can be done either with patches
or BK changesets; the amount of work required is pretty much the same
either way.)
Similarly, for the boot code I look to Tom and for the powermac
support I look to Ben Herrenschmidt. For the 4xx stuff there isn't
really a maintainer at the moment, unfortunately, except that Matt
Porter is looking after the 44x boards. I look after the classic
PowerPC core support -- exception handling, memory management, etc.,
and to some extent the 4xx core support, and the CHRP port.
What this boils down to is that for changes in these areas I expect
the maintainers for those areas to be packaging up the changes with
explanations, ready to go upstream. Anyone is of course welcome to
put together a patch + explanation and propose that it go upstream.
In such cases I would ask the maintainer for that area for his
opinion, or if there isn't a maintainer, I would ask the submitter if
they will commit to maintaining that area of the code. If they won't,
I would tend to drop the patch unless it is a simple, obviously
correct bugfix.
One problem we have at present is that there are a number of board
ports which don't appear to have a maintainer. Sometimes there are
people using those ports but noone taking responsibility for updating
it and keeping it working as things change elsewhere in the kernel.
Having a maintainer is a prerequisite for the board port to be sent
upstream.
I hope this clarifies things. If you want the kernel.org trees to
support your platform, then I suggest you put together the changes you
want to see as patches and send them to me and the maintainer for the
subarea. Make sure that the patch comes with a good explanation of
the change, and if you think the patch should go upstream, say so. If
possible make sure that the patch isn't too large. If it is large,
see if you can split it up into smaller patches, each of which
contains a logically related set of changes.
Regards,
Paul.
--
J.G.J. Boor Anton Philipsweg 1
Software Engineer 1223 KZ Hilversum
AimSys bv tel. +31 35 689 1941
Postbus 2194, 1200 CD Hilversum mailto:jjboor@aimsys.nl
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Thu, Mar 25, 2004 at 08:57:47AM +0100, Jaap-Jan Boor wrote:
On Mar 24, 2004, at 23:25, Tom Rini wrote:
quoted
quoted
quoted
It seems to be a circuitous route that I don't even understand
anymore. Sometime stuff I check in gets there, sometimes not. :-)
and you have never found out the conditions when something
get's in (only when submitted at friday the 13th or something?)
Um, yeah. I'm hoping 2.6 will be different from 2.4 in that regard. :)
ok!
quoted
linuxppc-2.[45] are children of the linux-2.[45] trees, and contain
stuff that's not quite ready to go out, _but_will_be_soon_ or has been
put in a tree for Linus/Marcelo, but they haven't pulled yet.
ok thanks (and linuxppc-2.5 should be used to get something into 2.6?)
If it's something which isn't quite ready yet, it should go into
linuxppc-2.5. Otherwise, it should go to linux-2.5, either via Andrew
Morton, or Paul or Ben sending it to Linus.
--
Tom Rini
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
linuxppc-2.[45] are children of the linux-2.[45] trees, and contain
stuff that's not quite ready to go out, _but_will_be_soon_ or has been
put in a tree for Linus/Marcelo, but they haven't pulled yet.
ok thanks (and linuxppc-2.5 should be used to get something into 2.6?)
If it's something which isn't quite ready yet, it should go into
linuxppc-2.5. Otherwise, it should go to linux-2.5, either via Andrew
Morton, or Paul or Ben sending it to Linus.
If the chnage goes directly to linux-2.[56] tree directly is it also
applied to linuxppc-2.5 as well? How do you keep it in sync with
kernel.org tree?
My logic says that if the changes that goes to kernel.org 2.6 tree is not
incorporated to linuxppc 2.5 tree we have a major problem. It would be too
difficult to keep track of which tree has which.
I would rather like to think that kernel.org has a subset of ppc specific
chnages that goes to linuxppc but linuxppc has all the changes that goes
to kernel.org linux tree.
Best regards,
Tolunay Orkun
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Thu, Mar 25, 2004 at 03:14:22PM -0600, Tolunay Orkun wrote:
quoted
quoted
quoted
linuxppc-2.[45] are children of the linux-2.[45] trees, and contain
stuff that's not quite ready to go out, _but_will_be_soon_ or has been
put in a tree for Linus/Marcelo, but they haven't pulled yet.
ok thanks (and linuxppc-2.5 should be used to get something into 2.6?)
If it's something which isn't quite ready yet, it should go into
linuxppc-2.5. Otherwise, it should go to linux-2.5, either via Andrew
Morton, or Paul or Ben sending it to Linus.
If the chnage goes directly to linux-2.[56] tree directly is it also
applied to linuxppc-2.5 as well? How do you keep it in sync with
kernel.org tree?
The linuxppc-2.5 tree is a child of the linux-2.5 tree. Once a change
gets into the linux-2.5 tree, we can pull it into the linuxppc-2.5 tree.
So it becomes just another change we get.
--
Tom Rini
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
If the chnage goes directly to linux-2.[56] tree directly is it also
applied to linuxppc-2.5 as well? How do you keep it in sync with
kernel.org tree?
The linuxppc-2.5 tree is a child of the linux-2.5 tree. Once a change
gets into the linux-2.5 tree, we can pull it into the linuxppc-2.5 tree.
So it becomes just another change we get.
OK. I was alarmed for no reason then.
Regards,
Tolunay Orkun
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/