From: Randolph Chung <randolph@tausq.org>
To: Carlos O'Donell <carlos@baldric.uwo.ca>
Cc: James Bottomley <James.Bottomley@steeleye.com>,
PARISC list <parisc-linux@lists.parisc-linux.org>
Subject: Re: [parisc-linux] [RFC] Revamp exception handling in the kernel
Date: Sun, 12 Sep 2004 09:15:51 -0700 [thread overview]
Message-ID: <20040912161550.GR28659@tausq.org> (raw)
In-Reply-To: <20040912134707.GL1854@baldric.uwo.ca>
> > One downside of this approach is that the extra fixup sections take up
> > more space, so the end kernel is bigger. In my test on 64-bit, the
> > kernel size increases by ~2%.
>
> What is that converted to bytes?
about 100k for 64-bit. should be significantly less for 32-bit.
> Is there ever a case where you want only the faulting instruction and
> not the faulting address aswell? This might be a case for saving a flag,
> if you are going to write to r9 you might aswell write two words,
> anyway? The code has already locked r8/r9 into variables and gcc won't
> do a better job for you.
actually a nice effect of this patch is that you don't need to lock down
r8 and r9 anymore for the get_user/put_user cases. Potentially any
register can be used to store the error and result values.
i need to do some experiments to verify this, but after thinking
about it more last night, it seems to me that we don't even need to put
the isr/ior into registers in the fault handler. the fixup code could
potentially just look at current->thread.regs.isr/ior directly.
> 0x2 = 1 then Write r8/r9 values (slow path)
> 0x2 = 0 then do nothing (fast path)
>
> Then 0x1 is free to be used for something magical.
sure, that works too.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
next prev parent reply other threads:[~2004-09-12 16:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-11 16:53 [parisc-linux] [RFC] Revamp exception handling in the kernel Randolph Chung
2004-09-11 22:49 ` John David Anglin
2004-09-12 13:10 ` Carlos O'Donell
2004-09-12 13:47 ` Carlos O'Donell
2004-09-12 13:58 ` James Bottomley
2004-09-12 14:29 ` Carlos O'Donell
2004-09-12 15:03 ` James Bottomley
2004-09-12 16:15 ` Randolph Chung [this message]
2004-09-12 17:54 ` Carlos O'Donell
2004-09-12 18:48 ` Randolph Chung
2004-09-12 19:19 ` Carlos O'Donell
2004-09-13 23:37 ` Randolph Chung
2004-09-14 2:37 ` Randolph Chung
2004-09-14 18:52 ` Joel Soete
[not found] <20040914160613.GA28659@tausq.org>
2004-09-14 22:36 ` Carlos O'Donell
[not found] ` <41487C05.3010606@tiscali.be>
[not found] ` <41487D4C.2020004@tiscali.be>
2004-09-16 14:31 ` Carlos O'Donell
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=20040912161550.GR28659@tausq.org \
--to=randolph@tausq.org \
--cc=James.Bottomley@steeleye.com \
--cc=carlos@baldric.uwo.ca \
--cc=parisc-linux@lists.parisc-linux.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