diff options
Diffstat (limited to 'microkernel/mach/gnumach')
| -rw-r--r-- | microkernel/mach/gnumach/debugging.mdwn | 15 | ||||
| -rw-r--r-- | microkernel/mach/gnumach/memory_management.mdwn | 30 |
2 files changed, 42 insertions, 3 deletions
diff --git a/microkernel/mach/gnumach/debugging.mdwn b/microkernel/mach/gnumach/debugging.mdwn index 3a93c6ad..2f52adf8 100644 --- a/microkernel/mach/gnumach/debugging.mdwn +++ b/microkernel/mach/gnumach/debugging.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2009, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -6,8 +6,8 @@ id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] Mach has a built-in kernel debugger. [Manual](http://www.gnu.org/software/hurd/gnumach-doc/Kernel-Debugger.html). @@ -67,3 +67,12 @@ The call of `halt_cpu` will -- as the name suggests -- halt the system afterwards. This might be what you want or it might not, but it is needed at some place when running the kernel inside QEMU, as QEMU somehow decides not to update its display buffer anymore under certain conditions. + + +IRC, freenode, #hurd, 2011-07-14: + + <braunr> one ugly trick i use when printf isn't available is to halt the + cpu + <braunr> then use info registers to know where the cpu is halted + <braunr> and you'll know if you reached that code or not + <braunr> (info registers is a qemu command) diff --git a/microkernel/mach/gnumach/memory_management.mdwn b/microkernel/mach/gnumach/memory_management.mdwn index 17c7ad79..43b99d83 100644 --- a/microkernel/mach/gnumach/memory_management.mdwn +++ b/microkernel/mach/gnumach/memory_management.mdwn @@ -50,3 +50,33 @@ IRC, freenode, #hurd, 2011-02-16 <braunr> antrik: but you're right, since mach uses a direct mapped kernel space, the true problem is the lack of linux-like highmem support <braunr> which isn't required if the kernel space is really virtual + + +--- + +IRC, freenode, #hurd, 2011-06-09 + + <braunr> btw, how can gnumach use 1 GiB of RAM ? did you lower the + user/kernel boundary address ? + <youpi> I did + <braunr> 2G ? + <youpi> yes + <braunr> ok + <youpi> it doesn't make so much sense to let processes have 3G addressing + space when there can't be more that 1G physical memory + <braunr> that's sad for an operating system which does most things by + mapping memory eh + <youpi> well, if a process wants to map crazy things, 3G may be tight + already + <youpi> e.g. ext2fs + <braunr> yes + <youpi> so there's little point in supporting them + <braunr> we need hurd/amd64 + <youpi> and there's quite some benefit in shrinking them to 2G + <youpi> yes + <youpi> actually even 2G may become a bit tight + <youpi> webkit linking needs about 1.5-2GiB + <youpi> things become really crazy + <braunr> wow + <braunr> i remember the linux support for 4G/4G split when there was enough + RAM to fill the kernel space with struct page entries |