tstarr/yuzu
1
0
Fork 0
mirror of https://github.com/starr-dusT/yuzu-mainline synced 2024-03-05 21:12:25 -08:00
Code Issues Packages Projects Releases Wiki Activity
e3ee017e91
yuzu/src/core/hle/kernel/object.cpp

38 lines
959 B
C++
Raw Normal View History

kernel: Move object class to its own source files General moving to keep kernel object types separate from the direct kernel code. Also essentially a preliminary cleanup before eliminating global kernel state in the kernel code.
2018-08-01 19:40:00 -07:00
// Copyright 2018 Citra Emulator Project
// Licensed under GPLv2 or any later version
// Refer to the license.txt file included.
#include "common/assert.h"
kernel: Eliminate kernel global state 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.
2018-08-28 09:30:33 -07:00
#include "core/hle/kernel/kernel.h"
kernel: Move object class to its own source files General moving to keep kernel object types separate from the direct kernel code. Also essentially a preliminary cleanup before eliminating global kernel state in the kernel code.
2018-08-01 19:40:00 -07:00
#include "core/hle/kernel/object.h"
namespace Kernel {
kernel: Eliminate kernel global state 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.
2018-08-28 09:30:33 -07:00
Object::Object(KernelCore& kernel) : kernel{kernel}, object_id{kernel.CreateNewObjectID()} {}
kernel: Move object class to its own source files General moving to keep kernel object types separate from the direct kernel code. Also essentially a preliminary cleanup before eliminating global kernel state in the kernel code.
2018-08-01 19:40:00 -07:00
Object::~Object() = default;
bool Object::IsWaitable() const {
switch (GetHandleType()) {
kernel/object: Amend handle types to distinguish between readable and writable events Two kernel object should absolutely never have the same handle ID type. This can cause incorrect behavior when it comes to retrieving object types from the handle table. In this case it allows converting a WritableEvent into a ReadableEvent and vice-versa, which is undefined behavior, since the object types are not the same. This also corrects ClearEvent() to check both kernel types like the kernel itself does.
2018-12-03 19:50:16 -08:00
case HandleType::ReadableEvent:
kernel: Move object class to its own source files General moving to keep kernel object types separate from the direct kernel code. Also essentially a preliminary cleanup before eliminating global kernel state in the kernel code.
2018-08-01 19:40:00 -07:00
case HandleType::Thread:
kernel/process: Make Process a WaitObject Process instances can be waited upon for state changes. This is also utilized by svcResetSignal, which will be modified in an upcoming change. This simply puts all of the WaitObject related machinery in place.
2018-12-04 16:08:56 -08:00
case HandleType::Process:
kernel: Move object class to its own source files General moving to keep kernel object types separate from the direct kernel code. Also essentially a preliminary cleanup before eliminating global kernel state in the kernel code.
2018-08-01 19:40:00 -07:00
case HandleType::ServerPort:
case HandleType::ServerSession:
return true;
case HandleType::Unknown:
kernel/object: Amend handle types to distinguish between readable and writable events Two kernel object should absolutely never have the same handle ID type. This can cause incorrect behavior when it comes to retrieving object types from the handle table. In this case it allows converting a WritableEvent into a ReadableEvent and vice-versa, which is undefined behavior, since the object types are not the same. This also corrects ClearEvent() to check both kernel types like the kernel itself does.
2018-12-03 19:50:16 -08:00
case HandleType::WritableEvent:
kernel: Move object class to its own source files General moving to keep kernel object types separate from the direct kernel code. Also essentially a preliminary cleanup before eliminating global kernel state in the kernel code.
2018-08-01 19:40:00 -07:00
case HandleType::SharedMemory:
core/hle/kernel: Split transfer memory handling out into its own class Within the kernel, shared memory and transfer memory facilities exist as completely different kernel objects. They also have different validity checking as well. Therefore, we shouldn't be treating the two as the same kind of memory. They also differ in terms of their behavioral aspect as well. Shared memory is intended for sharing memory between processes, while transfer memory is intended to be for transferring memory to other processes. This breaks out the handling for transfer memory into its own class and treats it as its own kernel object. This is also important when we consider resource limits as well. Particularly because transfer memory is limited by the resource limit value set for it. While we currently don't handle resource limit testing against objects yet (but we do allow setting them), this will make implementing that behavior much easier in the future, as we don't need to distinguish between shared memory and transfer memory allocations in the same place.
2019-03-13 00:09:27 -07:00
case HandleType::TransferMemory:
kernel: Move object class to its own source files General moving to keep kernel object types separate from the direct kernel code. Also essentially a preliminary cleanup before eliminating global kernel state in the kernel code.
2018-08-01 19:40:00 -07:00
case HandleType::ResourceLimit:
case HandleType::ClientPort:
case HandleType::ClientSession:
return false;
}
UNREACHABLE();
Fixed uninitialized memory due to missing returns in canary Functions which are suppose to crash on non canary builds usually don't return anything which lead to uninitialized memory being used.
2018-12-18 17:52:32 -08:00
return false;
kernel: Move object class to its own source files General moving to keep kernel object types separate from the direct kernel code. Also essentially a preliminary cleanup before eliminating global kernel state in the kernel code.
2018-08-01 19:40:00 -07:00
}
} // namespace Kernel
Reference in New Issue Copy Permalink