Skip to content
Snippets Groups Projects
  1. Mar 16, 2019
    • Lioncash's avatar
      kernel/thread: Amend condition within UpdatePriority() · 39483b92
      Lioncash authored
      This condition was checking against the nominal thread priority, whereas
      the kernel itself checks against the current priority instead. We were
      also assigning the nominal priority, when we should be assigning
      current_priority, which takes priority inheritance into account.
      
      This can lead to the incorrect priority being assigned to a thread.
      
      Given we recursively update the relevant threads, we don't need to go
      through the whole mutex waiter list. This matches what the kernel does
      as well (only accessing the first entry within the waiting list).
      39483b92
    • Lioncash's avatar
      kernel/thread: Maintain priority ordering of added mutex waiting threads · 0b78cfcc
      Lioncash authored
      The kernel keeps the internal waiting list ordered by priority. This is
      trivial to do with std::find_if followed by an insertion.
      0b78cfcc
  2. Mar 05, 2019
  3. Feb 16, 2019
    • Lioncash's avatar
      core_timing: Convert core timing into a class · bd983414
      Lioncash authored
      Gets rid of the largest set of mutable global state within the core.
      This also paves a way for eliminating usages of GetInstance() on the
      System class as a follow-up.
      
      Note that no behavioral changes have been made, and this simply extracts
      the functionality into a class. This also has the benefit of making
      dependencies on the core timing functionality explicit within the
      relevant interfaces.
      bd983414
  4. Feb 12, 2019
  5. Dec 28, 2018
    • Lioncash's avatar
      kernel/thread: Move process thread initialization into process.cpp · 771431f6
      Lioncash authored
      This function isn't a general purpose function that should be exposed to
      everything, given it's specific to initializing the main thread for a
      Process instance.
      
      Given that, it's a tad bit more sensible to place this within
      process.cpp, which keeps it visible only to the code that actually needs
      it.
      771431f6
  6. Dec 19, 2018
  7. Dec 18, 2018
  8. Dec 04, 2018
  9. Dec 03, 2018
  10. Nov 22, 2018
  11. Nov 19, 2018
  12. Nov 14, 2018
  13. Oct 30, 2018
  14. Oct 20, 2018
    • Lioncash's avatar
      kernel/process: Make the handle table per-process · 90a981a0
      Lioncash authored
      In the kernel, there isn't a singular handle table that everything gets
      tossed into or used, rather, each process gets its own handle table that
      it uses. This currently isn't an issue for us, since we only execute one
      process at the moment, but we may as well get this out of the way so
      it's not a headache later on.
      90a981a0
  15. Oct 15, 2018
  16. Oct 12, 2018
  17. Oct 10, 2018
    • Lioncash's avatar
      kernel/thread: Use a regular pointer for the owner/current process · 5c040859
      Lioncash authored
      There's no real need to use a shared pointer in these cases, and only
      makes object management more fragile in terms of how easy it would be to
      introduce cycles. Instead, just do the simple thing of using a regular
      pointer. Much of this is just a hold-over from citra anyways.
      
      It also doesn't make sense from a behavioral point of view for a
      process' thread to prolong the lifetime of the process itself (the
      process is supposed to own the thread, not the other way around).
      5c040859
  18. Oct 05, 2018
    • balika011's avatar
      thread: Make the scheduler pointer a regular pointer · 1a5d6de0
      balika011 authored
      Conceptually, it doesn't make sense for a thread to be able to persist
      the lifetime of a scheduler. A scheduler should be taking care of the
      threads; the threads should not be taking care of the scheduler.
      
      If the threads outlive the scheduler (or we simply don't actually
      terminate/shutdown the threads), then it should be considered a bug
      that we need to fix.
      
      Attributing this to balika011, as they opened #1317 to attempt to fix
      this in a similar way, but my refactoring of the kernel code caused
      quite a few conflicts.
      1a5d6de0
  19. Oct 04, 2018
    • Lioncash's avatar
      kernel/thread: Make all instance variables private · baed7e1f
      Lioncash authored
      Many of the member variables of the thread class aren't even used
      outside of the class itself, so there's no need to make those variables
      public. This change follows in the steps of the previous changes that
      made other kernel types' members private.
      
      The main motivation behind this is that the Thread class will likely
      change in the future as emulation becomes more accurate, and letting
      random bits of the emulator access data members of the Thread class
      directly makes it a pain to shuffle around and/or modify internals.
      Having all data members public like this also makes it difficult to
      reason about certain bits of behavior without first verifying what parts
      of the core actually use them.
      
      Everything being public also generally follows the tendency for changes
      to be introduced in completely different translation units that would
      otherwise be better introduced as an addition to the Thread class'
      public interface.
      baed7e1f
  20. Sep 30, 2018
    • Lioncash's avatar
      kernel/process: Make data member variables private · cf9d6c6f
      Lioncash authored
      Makes the public interface consistent in terms of how accesses are done
      on a process object. It also makes it slightly nicer to reason about the
      logic of the process class, as we don't want to expose everything to
      external code.
      cf9d6c6f
  21. Sep 25, 2018
    • Lioncash's avatar
      memory: Dehardcode the use of fixed memory range constants · 83377113
      Lioncash authored
      The locations of these can actually vary depending on the address space
      layout, so we shouldn't be using these when determining where to map
      memory or be using them as offsets for calculations. This keeps all the
      memory ranges flexible and malleable based off of the virtual memory
      manager instance state.
      83377113
  22. Sep 21, 2018
  23. Sep 18, 2018
    • Lioncash's avatar
      arm_interface: Remove ARM11-isms from the CPU interface · b51e7e02
      Lioncash authored
      This modifies the CPU interface to more accurately match an
      AArch64-supporting CPU as opposed to an ARM11 one. Two of the methods
      don't even make sense to keep around for this interface, as Adv Simd is
      used, rather than the VFP in the primary execution state. This is
      essentially a modernization change that should have occurred from the
      get-go.
      b51e7e02
  24. Sep 15, 2018
  25. Sep 12, 2018
  26. Aug 31, 2018
    • Lioncash's avatar
      core/core: Replace includes with forward declarations where applicable · 4a587b81
      Lioncash authored
      The follow-up to e2457418, which
      replaces most of the includes in the core header with forward declarations.
      
      This makes it so that if any of the headers the core header was
      previously including change, then no one will need to rebuild the bulk
      of the core, due to core.h being quite a prevalent inclusion.
      
      This should make turnaround for changes much faster for developers.
      4a587b81
  27. Aug 29, 2018
    • Lioncash's avatar
      kernel: Eliminate kernel global state · 0cbcd6ec
      Lioncash authored
      As means to pave the way for getting rid of global state within core,
      This eliminates kernel global state by removing all globals. Instead
      this introduces a KernelCore class which acts as a kernel instance. This
      instance lives in the System class, which keeps its lifetime contained
      to the lifetime of the System class.
      
      This also forces the kernel types to actually interact with the main
      kernel instance itself instead of having transient kernel state placed
      all over several translation units, keeping everything together. It also
      has a nice consequence of making dependencies much more explicit.
      
      This also makes our initialization a tad bit more correct. Previously we
      were creating a kernel process before the actual kernel was initialized,
      which doesn't really make much sense.
      
      The KernelCore class itself follows the PImpl idiom, which allows
      keeping all the implementation details sealed away from everything else,
      which forces the use of the exposed API and allows us to avoid any
      unnecessary inclusions within the main kernel header.
      0cbcd6ec
  28. Aug 25, 2018
  29. Aug 13, 2018
  30. Aug 12, 2018
  31. Aug 04, 2018
  32. Aug 03, 2018
  33. Aug 02, 2018
Loading