Skip to content
Snippets Groups Projects
  1. Oct 12, 2018
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. Sep 21, 2018
  8. 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
  9. Sep 15, 2018
  10. Sep 12, 2018
  11. 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
  12. 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
  13. Aug 25, 2018
  14. Aug 13, 2018
  15. Aug 12, 2018
  16. Aug 04, 2018
  17. Aug 03, 2018
  18. Aug 02, 2018
  19. 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
  20. Jul 24, 2018
  21. Jul 21, 2018
  22. Jul 20, 2018
  23. Jul 18, 2018
  24. Jul 03, 2018
  25. Jun 21, 2018
  26. 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
  27. May 31, 2018
  28. May 30, 2018
  29. May 10, 2018
Loading