Various inaccuracies in the emulator about skyline HOT 1 CLOSED

Thanks for the feedback again. We discussed some points in DMs, I'll cover the rest here and give a summary for other people.

Services & The kernel should be separated. Services do not live in the kernel, they live in sysmodules/builtins.

• I agree, I'll move them outside of the kernel folder

Various interfaces are not handled correctly(see am & hid interfaces). A global reference to an interface that are not named breaks multi-calls to the creation of interfaces and multi-processes.

• I actually noticed this as well, what I plan to do is essentially seperate creation of subinterfaces and normal services. This is already somewhat in with ServiceManager::RegisterService, I'll just remove the registration part and make it purely insert the service into the response and do nothing else.

You should not be allowed to register services with the same name without unregistering the first one

• This ties into the above point, I'll basically prevent multiple instances of normal services but let there be multiple instances of subinterface objects.

Service names NEED to be > 0 and < 9

• I'm not sure if you mean the names in 'ServiceString' or checking them in 'sm::GetService':
• In the first case, all service names that exceed 8 characters are purely there for reverse lookup of the service names.
• In the second case, the limit is implicit as no service will go over 8 characters.

Threading/Scheduling does not match nintendos kernel

• This is a known issue, I'm deferring it's implementation till I run into softlocks so I can test what works and what doesn't.

KEvent doesn't implement KReadableEvent & KWritableEvent

• This decision was made based on our core philosophy which is to replicate the behavior of HOS but be flexible with the structure. In this case, combining the two made sense as the difference between the two is essentially the mutability which is tiny enough where we can manage with combining them.

Various enums are unscoped

• I just checked, there seem to be 3 enums that are unscoped:
• Logger::LogLevel - This is meant to be unscoped so it'll leak into the Logger class and can be used to specifiy the log level without longer statements.
• FsType - This was a mistake, I just forgot to make it scoped.
• SystemClockType - Same as above, I just forgot to make it scoped.

All of fatals cmds are not the same. ThrowFatal only throws a error code, ThrowFatalWithPolicy throws an error code and a fatal type, lastly ThrowFatalWithCpuContext throws an error code, a fatal type and the current cpu context.
Fatals error codes return a ResultCode which can be unpacked.

• The fatal service was just something I threw together in fifteen minutes. So I didn't get the chance to actually add the extra information provided by the other functions. This is definitely something I need to get to and implement.

JoyConSide has no field known as "Unset"
JoyConOrientation has no field known as "Unset"
JoyConAssignment has no field known as "Unset"

• This ties back into decision to replicate the behavior of HOS but not it's structure, that enumeration will basically be invisible to the program and just there for better internal management of states.

SetNpadJoyAssignmentModeSingleByDefault should set the orientation for one controller, not all of them

• Got it, I'll fix this when I come back to HID.

JoyConDevices should not be considered as system controllers by default

• I did write a TODO in 'hid.h' for replacing JoyConDevice with NpadDevice instead. I suppose this ties into that.

Various cmds which are supposed to have result codes written do not write them

• As discussed, I haven't added error checking for the most part yet as I was under the assumption that applications won't try to explicitly do things wrong. This is definitely something I'll get to.

Thread yielding isn't accurate

• You're right, essentially a yield does nothing because the calling any SVC will suspend a thread till the kernel doesn't parse it's request and that's somewhat like a preemptive yield. However, I don't intend to keep it that way. I'm just waiting for a game that actually uses yielding so I can implement it and test it.

Memory permissions are not accurate

• Placeholder till I get clarifications about this

Kernel doesn't do checks to ensure that only virtual addresses can be used for objects passed to the kernel

• The kernel and application address space are completely segmented as we have 1:1 Host:Guest process mapping.

Missing resource limits

• Right, this is something I'll add including the SVC used to query the instances of a particular resource being used at the moment.

WaitSynchronization is incomplete

• As discussed, most SVCs don't have error checking code in them. I'll take some time to look over all of them and fix their behavior.

Addresses are not checked for alignment in the kernel

• This is actually something I have done willfully as I don't want to add a lot of extra cycles for tons of error checking but it may be interesting to have a debug flag that enables a whole bunch of error checking. I'll stick to mostly errors that actually return some error code to the application for release.

Mutex locks & Mutex unlocks always succeed when they shouldn't

• This ties in with SVCs in general not having correct error checking. I'll fix this as well.

SignalProcessWideKey is incomplete

• I'll fix this too, in regards to adding error checking.

OutputDebugString shouldn't write to a register, only read

• I was following Switchbrew's SVC page, it has output of the result to the W0 register

GetInfo inaccuracies

• Yep, I'll get to working on GetInfo after we implement more loaders so I can finish it once and for all.

KSharedMemory inherits from KAutoObject, not KObject

• This tends to fall into our core philosophy too, we can differ from HOS in some ways and what'll matter is basically just the interface provided to the application should be equivalent which it is in this case.

from skyline.