* [parisc-linux] Re: [parisc-linux-cvs] linux-2.5 jejb
[not found] <20030211004917.33A12482E@dsl2.external.hp.com>
@ 2003-02-11 0:58 ` James Bottomley
0 siblings, 0 replies; 5+ messages in thread
From: James Bottomley @ 2003-02-11 0:58 UTC (permalink / raw)
To: parisc-linux; +Cc: parisc-linux-cvs
On Mon, 2003-02-10 at 18:49, James Bottomley wrote:
> CVSROOT: /var/cvs
> Module name: linux-2.5
> Changes by: jejb 03/02/10 17:49:17
>
> Modified files:
> arch/parisc/kernel: init_task.c signal.c
> include/asm-parisc: ptrace.h
>
> Log message:
> Update for new kernel signal/sigaction split to replace sig
I should add a warning here that doing this has eliminated the pa-risc
private PTRACE_SETSIGINFO and PTRACE_GETSIGINFO definitions in favour of
the newly minted global kernel ones in linux/ptrace.h
Unfortunately, the values have changed, so some user space tracing tools
that relied on these may have to change.
I think they were unused previously, so all may be well, but someone who
knows this area should check.
James
^ permalink raw reply [flat|nested] 5+ messages in thread
* [parisc-linux] Re: [parisc-linux-cvs] linux-2.5 jejb
[not found] <20030216181021.6A8514829@dsl2.external.hp.com>
@ 2003-02-17 15:57 ` Carlos O'Donell
2003-02-17 16:30 ` James Bottomley
0 siblings, 1 reply; 5+ messages in thread
From: Carlos O'Donell @ 2003-02-17 15:57 UTC (permalink / raw)
To: parisc-linux; +Cc: James Bottomley
> CVSROOT: /var/cvs
> Module name: linux-2.5
> Changes by: jejb 03/02/16 11:10:21
>
> Modified files:
> arch/parisc/kernel: signal.c sys32.h
> include/asm-parisc: signal.h
>
> Log message:
> More signal change fixes
Thanks for all the great work James!
Just to comment on this, we have incorrect sigcontext's from 64-bit kernels.
If you look at the usage of "HACK" you'll see that the 32-bit userspace
gets some rather unusable 64-bit values in the sigcontext. I'm not sure how
other arches fix this? Cut off the top 32 bits?
This item is on my personal todo list, but I haven't talked to anyone who has
suggested a solution. I'm just a lowly GNU/Libc hacker, but if you suggest
something I _will_ write it.
c.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [parisc-linux] Re: [parisc-linux-cvs] linux-2.5 jejb
2003-02-17 15:57 ` Carlos O'Donell
@ 2003-02-17 16:30 ` James Bottomley
2003-02-17 21:07 ` Carlos O'Donell
0 siblings, 1 reply; 5+ messages in thread
From: James Bottomley @ 2003-02-17 16:30 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: parisc-linux
On Mon, 2003-02-17 at 10:57, Carlos O'Donell wrote:
> > CVSROOT: /var/cvs
> > Module name: linux-2.5
> > Changes by: jejb 03/02/16 11:10:21
> >
> > Modified files:
> > arch/parisc/kernel: signal.c sys32.h
> > include/asm-parisc: signal.h
> >
> > Log message:
> > More signal change fixes
>
> Thanks for all the great work James!
You're welcome, but these were really just compile fixes.
> Just to comment on this, we have incorrect sigcontext's from 64-bit kernels.
> If you look at the usage of "HACK" you'll see that the 32-bit userspace
> gets some rather unusable 64-bit values in the sigcontext. I'm not sure how
> other arches fix this? Cut off the top 32 bits?
>
> This item is on my personal todo list, but I haven't talked to anyone who has
> suggested a solution. I'm just a lowly GNU/Libc hacker, but if you suggest
> something I _will_ write it.
In general, we should probably be relying more on the generic 32/64
compatibility layer recently introduced. I suspect the best role model
for all of this is sparc64, since that's habitually run as a 64 bit
kernel with (mostly) 32 bit user space.
The HACK thing should continue to work OK as long as PA-RISC has no 64
bit user binary support, though.
James
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [parisc-linux] Re: [parisc-linux-cvs] linux-2.5 jejb
2003-02-17 16:30 ` James Bottomley
@ 2003-02-17 21:07 ` Carlos O'Donell
0 siblings, 0 replies; 5+ messages in thread
From: Carlos O'Donell @ 2003-02-17 21:07 UTC (permalink / raw)
To: James Bottomley; +Cc: parisc-linux
> > This item is on my personal todo list, but I haven't talked to anyone who has
> > suggested a solution. I'm just a lowly GNU/Libc hacker, but if you suggest
> > something I _will_ write it.
>
> In general, we should probably be relying more on the generic 32/64
> compatibility layer recently introduced. I suspect the best role model
> for all of this is sparc64, since that's habitually run as a 64 bit
> kernel with (mostly) 32 bit user space.
The sparc64 code is quite frightening, but I will look to it for a role
model.
> The HACK thing should continue to work OK as long as PA-RISC has no 64
> bit user binary support, though.
Yeah, it's OK until I attempt to write make/get/set/swap/context support
in libc :)
c.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [parisc-linux] Re: [parisc-linux-cvs] linux-2.5 jejb
[not found] <20030328054702.40ADD4829@dsl2.external.hp.com>
@ 2003-03-28 5:50 ` James Bottomley
0 siblings, 0 replies; 5+ messages in thread
From: James Bottomley @ 2003-03-28 5:50 UTC (permalink / raw)
To: parisc-linux; +Cc: parisc-linux-cvs
On Thu, 2003-03-27 at 23:47, James Bottomley wrote:
> CVSROOT: /var/cvs
> Module name: linux-2.5
> Changes by: jejb 03/03/27 22:47:02
>
> Modified files:
> include/asm-parisc: pgtable.h
>
> Log message:
> Add support for file-offsets-in-pte's
>
> See http://mail.nl.linux.org/linux-mm/2003-03/msg00174.html
===== include/asm-parisc/pgtable.h 1.11 vs edited =====
--- 1.11/include/asm-parisc/pgtable.h Thu Mar 6 10:19:09 2003
+++ edited/include/asm-parisc/pgtable.h Thu Mar 27 21:42:26 2003
@@ -122,6 +122,7 @@
#define _PAGE_GATEWAY_BIT 28 /* (0x008) privilege promotion allowed */
#define _PAGE_DMB_BIT 27 /* (0x010) Data Memory Break enable (B bit) */
#define _PAGE_DIRTY_BIT 26 /* (0x020) Page Dirty (D bit) */
+#define _PAGE_FILE_BIT _PAGE_DIRTY_BIT /* overload this bit */
#define _PAGE_REFTRAP_BIT 25 /* (0x040) Page Ref. Trap enable (T bit) */
#define _PAGE_NO_CACHE_BIT 24 /* (0x080) Uncached Page (U bit) */
#define _PAGE_ACCESSED_BIT 23 /* (0x100) Software: Page Accessed */
@@ -135,6 +136,17 @@
#define xlate_pabit(x) (31 - x)
+/* this defines the shift to the usable bits in the PTE it is set so
+ * that the valid bits _PAGE_PRESENT_BIT and _PAGE_USER_BIT are set
+ * to zero */
+#define PTE_SHIFT xlate_pabit(_PAGE_USER_BIT)
+
+/* this is how many bits may be used by the file functions */
+#define PTE_FILE_MAX_BITS (BITS_PER_LONG - PTE_SHIFT)
+
+#define pte_to_pgoff(pte) (pte_val(pte) >> PTE_SHIFT)
+#define pgoff_to_pte(off) ((pte_t) { ((off) << PTE_SHIFT) | _PAGE_FILE })
+
#define _PAGE_READ (1 << xlate_pabit(_PAGE_READ_BIT))
#define _PAGE_WRITE (1 << xlate_pabit(_PAGE_WRITE_BIT))
#define _PAGE_RW (_PAGE_READ | _PAGE_WRITE)
@@ -148,6 +160,7 @@
#define _PAGE_PRESENT (1 << xlate_pabit(_PAGE_PRESENT_BIT))
#define _PAGE_FLUSH (1 << xlate_pabit(_PAGE_FLUSH_BIT))
#define _PAGE_USER (1 << xlate_pabit(_PAGE_USER_BIT))
+#define _PAGE_FILE (1 << xlate_pabit(_PAGE_FILE_BIT))
#define _PAGE_TABLE (_PAGE_PRESENT | _PAGE_READ | _PAGE_WRITE | _PAGE_DIRTY | _PAGE_ACCESSED)
#define _PAGE_CHG_MASK (PAGE_MASK | _PAGE_ACCESSED | _PAGE_DIRTY)
@@ -256,6 +269,7 @@
extern inline int pte_dirty(pte_t pte) { return pte_val(pte) & _PAGE_DIRTY; }
extern inline int pte_young(pte_t pte) { return pte_val(pte) & _PAGE_ACCESSED; }
extern inline int pte_write(pte_t pte) { return pte_val(pte) & _PAGE_WRITE; }
+extern inline int pte_file(pte_t pte) { return pte_val(pte) & _PAGE_FILE; }
extern inline pte_t pte_rdprotect(pte_t pte) { pte_val(pte) &= ~_PAGE_READ; return pte; }
extern inline pte_t pte_mkclean(pte_t pte) { pte_val(pte) &= ~_PAGE_DIRTY; return pte; }
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2003-03-28 5:50 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20030328054702.40ADD4829@dsl2.external.hp.com>
2003-03-28 5:50 ` [parisc-linux] Re: [parisc-linux-cvs] linux-2.5 jejb James Bottomley
[not found] <20030216181021.6A8514829@dsl2.external.hp.com>
2003-02-17 15:57 ` Carlos O'Donell
2003-02-17 16:30 ` James Bottomley
2003-02-17 21:07 ` Carlos O'Donell
[not found] <20030211004917.33A12482E@dsl2.external.hp.com>
2003-02-11 0:58 ` James Bottomley
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox