rearrangements in linuxppc_2_4_devel

Adrian Cox adrian at
Wed Jun 27 23:52:50 EST 2001

Paul Mackerras wrote:

> Adrian Cox writes:
>>APUS is probably broken, because it believes that it can call
>>parse_bootinfo with a pointer to the boot records. From apus_setup.c:
> APUS uses the m68k bootinfo format anyway, which ours is gratuitously
> different from.  The apus booter probably does pass the address in a
> register, which would actually be the sensible thing to do. :)

Looking at the makefile, APUS links with setup.c. So it's going to link
with our standard parse_bootinfo, which doesn't take any arguments. I
suspect APUS needs a bit more work to integrate it into the 2_4_devel tree.

>>Paul: would you take patches that moved some of this stuff into header
>>files, and if so, which header file would you like all the miscellaneous
>>setup functions to move into?

> Ummm, it would depend which functions you're talking about.  There is
> certainly an argument for having a couple more .h files in
> arch/ppc/kernel to declare functions that are used only in
> arch/ppc/kernel/*.c.

That's what I'm thinking of - I just want to cut down the number of
extern declarations in the C files in arch/ppc/kernel.

Candidate functions include things like xmon functions, and various
platform specific functions on the platforms I'm interested in. In some
cases we have declarations in header files, so I may remove the
duplication. I've been doing this since I started working on machine
check, as I found clashing uses of bad_page_fault(), fixed by the
attached patch.

Adrian Cox
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: badpage.patch
URL: <>

More information about the Linuxppc-dev mailing list