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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.