Mirror of github.com/cira0100/Eglantine-public nx2, a fork of Djihads80/Eglantine. https://git.cirakg.xyz/eglantine-cirakg/atom?h=nx2 2021-05-05T23:40:52+00:00 2021-05-05T23:40:52+00:00 bunnei bunneidev@gmail.com 2021-04-24T04:50:04+00:00 urn:sha1:796dddf78f6e622a559da674bacbb4a14b60c094 2021-02-05T22:03:32+00:00 bunnei bunneidev@gmail.com 2021-01-31T09:38:57+00:00 urn:sha1:0508831455a2e38d84b54947fb06bda84053d7e1 2019-11-28T17:01:53+00:00 bunnei bunneidev@gmail.com 2019-11-25T23:28:48+00:00 urn:sha1:4a4516868c18c84b391caaa321e8549547fb690c 2019-04-03T14:24:32+00:00 Lioncash mathew1800@gmail.com 2019-04-03T14:24:29+00:00 urn:sha1:737f2889cbf545c04675a7a4298290c5a04cd62d The AddressArbiter type isn't actually used, given the arbiter itself isn't a direct kernel object (or object that implements the wait object facilities). Given this, we can remove the enum entry entirely. 2019-03-13T10:04:44+00:00 Lioncash mathew1800@gmail.com 2019-03-13T07:09:27+00:00 urn:sha1:4ed697697d5d49f5d5d93558fef63b22e7f923aa 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-02-01T04:05:15+00:00 Lioncash mathew1800@gmail.com 2019-02-01T04:05:00+00:00 urn:sha1:c6d2828c74737b54164ffb44abae12f8d9735d58 A holdover from citra, the Horizon kernel on the switch has no prominent kernel object that functions as a timer. At least not to the degree of sophistication that this class provided. As such, this can be removed entirely. This class also wasn't used at all in any meaningful way within the core, so this was just code sitting around doing nothing. This also allows removing a few things from the main KernelCore class that allows it to use slightly less resources overall (though very minor and not anything really noticeable). 2018-12-19T01:52:32+00:00 David Marcec dmarcecguzman@gmail.com 2018-12-19T01:52:32+00:00 urn:sha1:1dfb0a513a7bad3eae2c341cdae7d23fd9929500 Functions which are suppose to crash on non canary builds usually don't return anything which lead to uninitialized memory being used. 2018-12-05T01:14:59+00:00 Lioncash mathew1800@gmail.com 2018-12-05T00:08:56+00:00 urn:sha1:a007480e6ffcae0660131a44c273e1d791fed636 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-04T07:20:47+00:00 Lioncash mathew1800@gmail.com 2018-12-04T03:50:16+00:00 urn:sha1:59a4ed0d2477999e979373eb821f024bf0d9d4c6 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-10-12T16:07:32+00:00 Lioncash mathew1800@gmail.com 2018-10-12T15:36:31+00:00 urn:sha1:d1c7aa8c6cd926768078c67efe994bff8acf7b78 These only exist to ferry data into a Process instance and end up going out of scope quite early. Because of this, we can just make it a plain struct for holding things and just std::move it into the relevant function. There's no need to make this inherit from the kernel's Object type.