state of 4xx code in 2.5.x

state of 4xx code in 2.5.x

[Paul Mackerras]

I am becoming increasingly concerned about the quality, or lack of it,
of the 4xx code generally.  I think we need someone who has a good
amount of experience in Linux kernel coding to go through all the 4xx
code and clean it up and simplify it where possible.  I know that the
4xx family have quirks (e.g. DCRs) which make it difficult in places
to do things simply, but with a bit of creativity we can make the code
clearer and simpler than it is at the moment.

I should note that I mostly care about cleaning up the 4xx support in
2.5.x.  I don't want to make any major changes in linuxppc_2_4_devel
at this stage.

At the moment it seems that Tom Rini is the maintainer and Armin
Kuster and David Gibson are both working in the area, particularly on
the OCP support.  It seems though that Tom's life is very busy at the
moment with various things.  So I am proposing that I will take over
the 4xx maintainership for 2.5.x, at least for now, unless someone
else with a reasonable amount of kernel hacking cred steps forward and
volunteers to do it instead.

Paul.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: state of 4xx code in 2.5.x

[Roland Dreier]

>>>>> "Paul" == Paul Mackerras <paulus@samba.org> writes:

    Paul> I am becoming increasingly concerned about the quality, or
    Paul> lack of it, of the 4xx code generally.  I think we need
    Paul> someone who has a good amount of experience in Linux kernel
    Paul> coding to go through all the 4xx code and clean it up and
    Paul> simplify it where possible.  I know that the 4xx family have
    Paul> quirks (e.g. DCRs) which make it difficult in places to do
    Paul> things simply, but with a bit of creativity we can make the
    Paul> code clearer and simpler than it is at the moment.

Sounds great!  I don't have the time (or the kernel hacking cred,
probably) to do much more than cheer you on, unfortunately.  However I
would suggest that you start by proposing a design before you start
moving code around.  I definitely agree that there is far too much
duplicated and confusing code, but I don't think things will improve
without a clear articulation of what belongs where (ie what goes in
include/asm-ppc/, arch/ppc/platforms/, arch/ppc/kernel/ etc., and what
the difference is between 4xx.h, 405.h, 405gp.h)

Best,
  Roland

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/