linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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);

  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).