From 95878586ec7611791f4001a4ee17abf943fae3c1 Mon Sep 17 00:00:00 2001 From: "https://me.yahoo.com/a/g3Ccalpj0NhN566pHbUl6i9QF0QEkrhlfPM-#b1c14" Date: Mon, 16 Feb 2015 20:08:03 +0100 Subject: rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn --- .../gnumach_memory_management_physical_memory.mdwn | 46 ---------------------- 1 file changed, 46 deletions(-) delete mode 100644 open_issues/gnumach_memory_management_physical_memory.mdwn (limited to 'open_issues/gnumach_memory_management_physical_memory.mdwn') diff --git a/open_issues/gnumach_memory_management_physical_memory.mdwn b/open_issues/gnumach_memory_management_physical_memory.mdwn deleted file mode 100644 index 58fefe1f..00000000 --- a/open_issues/gnumach_memory_management_physical_memory.mdwn +++ /dev/null @@ -1,46 +0,0 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -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]]."]]"""]] - -[[!tag open_issue_gnumach]] - -IRC, freenode, #hurd, 2011-10: - - antrik: about our physical memory limitations, i told you some - time ago that part of it was due to the linux drivers - and i mentioned the paper concerning the integration of the linux - drivers written at the time - it does indeed tell that mach, which used the common 3G->4G area - for the kernel space had to be adapted - because linux used segmentation so that kernel addresses matched - physical addresses - and it looks like some (many) drivers require that - our current gnumach actually does this (which i found surprising - when i first found it) - and i believe the easy solution to exceed this limitation is to - use a strategy similar to what linux still does on i386 - some highmem support - we could alter the vm_resident module so that, by default, it - still looks for pages in the low 0-800 (or 0-1800 on debian patched - kernels) area - but for everything else than the kernel, e.g. all user processes - we could use a flag or a specialized function that would first - look in the highmem pool for available physical pages to map - the only thing i'm not yet sure of is about user/kernel transfers - if virtual addresses and copies are always cleanly done, then it's - ok - and i really hope our linux drivers do so :) - (i mean ,the glue code ofc) - -2011-10-23: - - braunr: I believe, like Linus, that highmem support is a nightmare - braunr: uhm... the drivers want virtual addressses to match - physical ones? I guess that means switching address spaces before any - driver code is executed?... -- cgit v1.2.3