[[!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_documentation]]

IRC, freenode, #hurd, 2011-02-15

    <braunr> etenil: originally, mach had its own virtual space (the kernel
      space)
    <braunr> etenil: in order to use linux 2.0 drivers, it now directly maps
      physical memory, as linux does
    <braunr> etenil: but there is nothing similar to kmap() or vmalloc() in
      mach, so the kernel is limited to its 1 GiB
    <braunr> (3 GiB userspace / 1 GiB kernelspace)
    <braunr> that's the short version, there is a vmalloc() in mach, but this
      trick made it behave almost like a kmalloc()
    <antrik> braunr: the direct mapping is *only* for the benefit of Linux
      drivers?...
    <braunr> also, the configuration of segments limits the kernel space
    <braunr> antrik: i'm not sure, as i said, this is the short version
    <braunr> antrik: but there is a paper which describes the integration of
      those drivers in mach
    <etenil> you mean the linux 2.0 drivers?
    <antrik> braunr: I read it once, but I don't remember anything about the
      physical mapping in there...
    <antrik> etenil: well, originally it was 1.3, but essentially that's the
      same...
    <braunr> i don't see any other reason why there would be a direct mapping
    <braunr> except for performance (because you can use larger - even very
      lage - pages without resetting the mmu often thanks to global pages, but
      that didn't exist at the time)

IRC, freenode, #hurd, 2011-02-15

    <antrik> however, the kernel won't work in 64 bit mode without some changes
      to physical memory management
    <braunr> and mmu management
    <braunr> (but maybe that's what you meant by physical memory)

IRC, freenode, #hurd, 2011-02-16

    <braunr> antrik: youpi added it for xen, yes
    <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