Skip to content
Snippets Groups Projects
  1. 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
  2. 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
  3. 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
  4. Sep 21, 2018
  5. 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
  6. Sep 15, 2018
  7. Sep 12, 2018
  8. 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
  9. 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
  10. Aug 25, 2018
  11. Aug 13, 2018
  12. Aug 12, 2018
  13. Aug 04, 2018
  14. Aug 03, 2018
  15. Aug 02, 2018
  16. Jul 31, 2018
    • Lioncash's avatar
      kernel: Remove unnecessary includes · a2304fad
      Lioncash authored
      Removes unnecessary direct dependencies in some headers and also gets
      rid of indirect dependencies that were being relied on to be included.
      a2304fad
  17. Jul 24, 2018
  18. Jul 21, 2018
  19. Jul 20, 2018
  20. Jul 18, 2018
  21. Jul 03, 2018
  22. Jun 21, 2018
  23. Jun 02, 2018
    • Subv's avatar
      Kernel/Threads: A thread waking up by timeout from a WaitProcessWideKey may... · 9cd87a63
      Subv authored
      Kernel/Threads: A thread waking up by timeout from a WaitProcessWideKey may already have an assigned lock owner.
      
      This situation may happen like so:
      Thread 1 with low priority calls WaitProcessWideKey with timeout.
      Thread 2 with high priority calls WaitProcessWideKey without timeout.
      Thread 3 calls SignalProcessWideKey
      - Thread 2 acquires the lock and awakens.
      - Thread 1 can't acquire the lock and is put to sleep with the lock owner being Thread 2.
      Thread 1's timeout expires, with the lock owner still being set to Thread 2.
      9cd87a63
  24. May 31, 2018
  25. May 30, 2018
  26. May 10, 2018
  27. Apr 30, 2018
Loading