-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wrap some SysMemForKernel's nids, fixing #7960 #7965
Conversation
@hrydgard this commit have problem ? |
As SysMemForUser in there
I move SysMemForKernel to sceKernelMemory |
std::string name; | ||
BlockAllocator alloc; | ||
static int GetStaticIDType() { return SCE_KERNEL_TMID_Fpl; }// wrong | ||
int GetIDType() const override { return SCE_KERNEL_TMID_Fpl; }// wrong |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I take a search but no SCE_KERNEL_TMID_HEAP
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
partitionId, name,flags,name not used
Not sure really need save status these variable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't use the "XyzInformation" convention in PPSSPP, even if JPCSP does. I really think we should have testing to understand how this differs from sceHeap. Also, testing can identify which TMID is uses - there's a syscall that gives you the type id for a uid, iirc.
I can't remember for sure, but I thought we used the TMID for savestates, though. I don't think it's good if they're wrong.
-[Unknown]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this pull request is not ready for v1.1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also yes,I copy most of code from sceHeap.cpp
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, it won't make it. we can start adding some kernel stuff after 1.1 but for now I want to keep things the way they are to be safe.
1.1 will be soon though, I'm planning to release next weekend.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See also PPSSPP_KERNEL_TMID_Module
and similar for using fake TMID values. For savestates to work correctly, we need unique values right now.
-[Unknown]
Unfortunately,the screen is still black after HLE\sceKernelThread.cpp:2851 sceKernelSuspendThread(276): cannot suspend current thread modify log: |
As this commit is work (tested on Tales of Phantasia with Chinese patch)
Just a note that my change is based on jpcsp/jpcsp@3c25717 |
@@ -2301,3 +2301,115 @@ void Register_SysMemUserForUser() | |||
{ | |||
RegisterModule("SysMemUserForUser", ARRAY_SIZE(SysMemUserForUser), SysMemUserForUser); | |||
} | |||
|
|||
|
|||
struct HeapInformation : public KernelObject { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should:
- Put these functions and structs in
sceKernelHeap.cpp
. - Keep
SysMemForKernel
here and export the functions insceKernelHeap.h
(kinda like sceKernelMutex.h, etc.)
-[Unknown]
This will need some rebasing and cleanup work but seems worthwhile if it gets Chinese language patches going, with not too much trouble. @sum2012 do you intend to improve this some more anytime soon? Otherwise I might clean it up a bit soon for you, but you'll have to test it. |
@hrydgard I remember this code not more work , maybe I transate something wrong |
Hm. Either way it needs a rebase if we should keep it open. Close or not? |
I would rebase it in Sunday in Hong Kong time |
Oh, there's absolutely no rush. Whenever you have time. 1.5 is still far away.. |
Closing this in favor of #12225. Sorry for the long delay ;) |
#7960
The log is better
https://gist.github.com/sum2012/2ab67196dc4a97ff60e7