1. 24 Mar, 2019 4 commits
    • Lioncash's avatar
      kernel/vm_manager: Handle case of identical calls to HeapAllocate · abdb81cc
      Lioncash authored
      In cases where HeapAllocate is called with the same size of the current
      heap, we can simply do nothing and return successfully.
      
      This avoids doing work where we otherwise don't have to. This is also
      what the kernel itself does in this scenario.
      abdb81cc
    • Lioncash's avatar
      kernel/vm_manager: Remove unused class variables · 9f63acac
      Lioncash authored
      Over time these have fallen out of use due to refactoring, so these can
      be removed.
      9f63acac
    • Lioncash's avatar
      kernel/vm_manager: Remove unnecessary heap_used data member · 52980df1
      Lioncash authored
      This isn't required anymore, as all the kernel ever queries is the size
      of the current heap, not the total usage of it.
      52980df1
    • Lioncash's avatar
      kernel/vm_manager: Tidy up heap allocation code · 586cab61
      Lioncash authored
      Another holdover from citra that can be tossed out is the notion of the
      heap needing to be allocated in different addresses. On the switch, the
      base address of the heap will always be managed by the memory allocator
      in the kernel, so this doesn't need to be specified in the function's
      interface itself.
      
      The heap on the switch is always allocated with read/write permissions,
      so we don't need to add specifying the memory permissions as part of the
      heap allocation itself either.
      
      This also corrects the error code returned from within the function.
      If the size of the heap is larger than the entire heap region, then the
      kernel will report an out of memory condition.
      586cab61
  2. 23 Mar, 2019 3 commits
  3. 22 Mar, 2019 16 commits
  4. 21 Mar, 2019 17 commits