| Age | Commit message (Collapse) | Author |
|---|
|
Given this is intended as a querying function, it doesn't make sense to
allow the implementer to modify the state of the given thread.
|
|
Previously this was performing a u64 + int sign conversion. When dealing
with addresses, we should generally be keeping the arithmetic in the
same signedness type.
This also gets rid of the static lifetime of the constant, as there's no
need to make a trivial type like this potentially live for the entire
duration of the program.
|
|
The pointed to member is never actually modified, so it can be made
const.
|
|
Since C++17, the introduction of deduction guides for locking facilities
means that we no longer need to hardcode the mutex type into the locks
themselves, making it easier to switch mutex types, should it ever be
necessary in the future.
|
|
kernel/process: Report total physical memory used to svcGetInfo slightly better
|
|
This was made unused in b404fcdf1443b91ac9994c05ad1fe039fcd9675e, but
the parameter itself wasn't removed.
|
|
Since C++17, we no longer need to explicitly specify the type of the
mutex within the lock_guard. The type system can now deduce these with
deduction guides.
|
|
Reports the (mostly) correct size through svcGetInfo now for queries to
total used physical memory. This still doesn't correctly handle memory
allocated via svcMapPhysicalMemory, however, we don't currently handle
that case anyways.
|
|
This will be necessary to properly report the used memory size in
svcGetInfo.
|
|
Kernel: Fixes to Arbitration and SignalProcessWideKey Management
|
|
Replace old Thread Queue for a new Multi Level Queue
|
|
This will be necessary in order to properly report memory usage within
svcGetInfo.
|
|
This will make operating with the process-related SVC commands much
nicer in the future (the parameter representing the stack size in
svcStartProcess is a 64-bit value).
|
|
The kernel always makes sure that the given stack size is aligned to
page boundaries.
|
|
kernel/vm_manager: Unify heap allocation/freeing functions
|
|
|
|
|
|
kernel/process: Remove unused AddressMapping struct
|
|
core/core_timing: Make callback parameters consistent
|
|
In some cases, our callbacks were using s64 as a parameter, and in other
cases, they were using an int, which is inconsistent.
To make all callbacks consistent, we can just use an s64 as the type for
late cycles, given it gets rid of the need to cast internally.
While we're at it, also resolve some signed/unsigned conversions that
were occurring related to the callback registration.
|
|
This is no longer necessary, as ResultVal isn't used anywhere in the
header.
|
|
Another leftover from citra that's now no longer necessary.
|
|
One behavior that we weren't handling properly in our heap allocation
process was the ability for the heap to be shrunk down in size if a
larger size was previously requested.
This adds the basic behavior to do so and also gets rid of HeapFree, as
it's no longer necessary now that we have allocations and deallocations
going through the same API function.
While we're at it, fully document the behavior that this function
performs.
|
|
Makes it more obvious that this function is intending to stand in for
the actual supervisor call itself, and not acting as a general heap
allocation function.
Also the following change will merge the freeing behavior of HeapFree
into this function, so leaving it as HeapAllocate would be misleading.
|
|
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.
|
|
Over time these have fallen out of use due to refactoring, so these can
be removed.
|
|
This isn't required anymore, as all the kernel ever queries is the size
of the current heap, not the total usage of it.
|
|
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.
|
|
core/hle/kernel: Split transfer memory handling out into its own class
|
|
core/hle/kernel: Make Mutex a per-process class.
|
|
kernel/vm_manager: Amend flag value for code data
|
|
file_sys: Implement parser and interpreter for game memory cheats
|
|
respectively
Makes it more evident that one is for actual code and one is for actual
data. Mutable and static are less than ideal terms here, because
read-only data is technically not mutable, but we were mapping it with
that label.
|
|
This should actually be using the data flags, rather than the code
flags.
|
|
core/kernel: Migrate CodeSet to its own source files
|
|
The segment itself isn't actually modified.
|
|
Given this is utilized by the loaders, this allows avoiding inclusion of
the kernel process definitions where avoidable.
This also keeps the loading format for all executable data separate from
the kernel objects.
|
|
|
|
|
|
|
|
|
|
kernel/thread: Amend conditional test and assignment within UpdatePriority()
|
|
core: Move PageTable struct into Common.
|
|
|
|
This was intended to be removed in
51d7f6bffcc0498a47abc7de27bf0906fc523dae, but I guess I forgot to
actually save the file like a dingus.
|
|
kernel/thread: Remove WaitCurrentThread_Sleep() and ExitCurrentThread()
|
|
Puts the operation on global state in the same places as the rest of the
svc calls.
|
|
Rather than make a global accessor for this sort of thing. We can make
it a part of the thread interface itself. This allows getting rid of a
hidden global accessor in the kernel code.
|
|
Aims to disambiguate why each priority instance exists a little bit.
While we're at it, also add an explanatory comment to UpdatePriority().
|
|
|
