Okay. I've adjusted the desciption of the patch a little (see attached).
David
---
From: Mike Frysinger vap...@gentoo.org
Subject: [PATCH] NOMMU: Add '[stack]' label to /proc/pid/maps output
Add support to the NOMMU /proc/pid/maps file to show which mapping is the stack
of the original thread
Try the char driver, it is simplest of three.
Sounds like a good plan. Thanks for your advice. I'm currently
following the ioctl route.
It's slightly complicated because my FPGA is effectively a bridge to a
number of hot-pluggable
backplane I/O cards. It seems to me that I should probably
On Tuesday 22 December 2009 18:11:30 David Wooff wrote:
So, although I could talk to my FPGA via ioctl commands, how should I
talk to the I/O cards
when they are plugged in? Should each of these be recognised as a
single char device?
My other option is to keep it simple and use the driver
From: Mike Frysinger vap...@gentoo.org
The current code will load the stack size and protection markings, but then
only use the markings in the MMU code path. The NOMMU code path always passes
PROT_EXEC to the mmap() call. While this doesn't matter to most people whilst
the code is running, it
From: Mike Frysinger vapier@gmail.com
When working with FDPIC, there are many shared mappings of read-only code
regions between applications (the C library, applet packages like busybox,
etc.), but the current do_mmap_pgoff() function will issue an icache flush
whenever a VMA is added to an
From: Daisuke HATAYAMA d.hatay...@jp.fujitsu.com
Commit f6151dfea21496d43dbaba32cfcd9c9f404769bc causes ELF-FDPIC to break
during building, so this patch fixes it together with a correction for the
printk format.
Signed-off-by: Daisuke HATAYAMA d.hatay...@jp.fujitsu.com
Reviewed-by: Masami
From: Jie Zhang jie.zh...@analog.com
The MMU code uses the copy_*_user_page() variants in access_process_vm()
rather than copy_*_user() as the former includes an icache flush. This is
important when doing things like setting software breakpoints with gdb.
So switch the NOMMU code over to do the
On December 22, 2009 11:11:30 am David Wooff wrote:
It's slightly complicated because my FPGA is effectively a bridge to a
number of hot-pluggable
backplane I/O cards. It seems to me that I should probably attempt to
structure it (the FPGA and backplane)
as a bus with I/O card devices
