From: Adrian Cox <adrian@humboldt.co.uk>
To: paulus@samba.org
Cc: linuxppc-commit@ppcbk.mvista.com, linuxppc-dev@lists.linuxppc.org
Subject: Re: rearrangements in linuxppc_2_4_devel
Date: Wed, 27 Jun 2001 14:52:50 +0100 [thread overview]
Message-ID: <3B39E532.7040202@humboldt.co.uk> (raw)
In-Reply-To: 15161.54515.559935.629883@cargo.ozlabs.ibm.com
[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]
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 http://www.humboldt.co.uk/
[-- Attachment #2: badpage.patch --]
[-- Type: text/plain, Size: 596 bytes --]
===== arch/ppc/kernel/traps.c 1.14 vs edited =====
--- 1.14/arch/ppc/kernel/traps.c Fri Jun 15 05:11:42 2001
+++ edited/arch/ppc/kernel/traps.c Wed Jun 27 14:46:32 2001
@@ -40,7 +40,6 @@
#include <asm/processor.h>
extern int fix_alignment(struct pt_regs *);
-extern void bad_page_fault(struct pt_regs *, unsigned long);
#ifdef CONFIG_XMON
extern void xmon(struct pt_regs *regs);
@@ -317,7 +316,7 @@
if (user_mode(regs))
force_sig(SIGSEGV, current);
else
- bad_page_fault(regs, regs->dar);
+ bad_page_fault(regs, regs->dar, SIGSEGV);
return;
}
_exception(SIGBUS, regs);
next prev parent reply other threads:[~2001-06-27 13:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-06-27 6:46 rearrangements in linuxppc_2_4_devel Paul Mackerras
2001-06-27 11:51 ` Adrian Cox
2001-06-27 12:43 ` Paul Mackerras
2001-06-27 13:52 ` Adrian Cox [this message]
2001-06-27 22:00 ` Roman Zippel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3B39E532.7040202@humboldt.co.uk \
--to=adrian@humboldt.co.uk \
--cc=linuxppc-commit@ppcbk.mvista.com \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).