Closed devnoname120 closed 7 years ago
There are some other symbols which have different prefixes such as vsh
. We may make clear what prefixes are reserved by the SDK.
Ok I've given this some thought and think I'll write this to begin some discussion by laying out some ideas. Since we've already established headers and names for user types (so far), we should exclude them from these discussions and opt in for compatibility with existing homebrew. Kernel API is a blank canvas for us, we're still in beta(tm) and can change as much as we want. So I suggest for kernel:
ForKernel
. e.g, sceIoOpen
to sceIoOpenForKernel
. We would not use the ForDriver
suffix.For new contributions:
sce
prefix, followed by a reasonable* name or abbreviation for the module it belongs to.camelCaseStyle
.As such, all sce
prefixes will be reserved by SDK.
sceKernel
when it comes to the various `ForKernel`` libraries.how about just use k
prefix or suffix for the kernel function?(like kSceIoOpen
or sceIoOpenK
)
ForKernel
is too long suffix.
We could do two prefixes:
ksce
for kernel functionssce
for user functionsThis would make it very clear that the developer is using the intended function.
For the record: adding a kernel prefix is not a technical limitation but a purposeful constraint to clearly convey to the developer which library they're attempting to use. Otherwise a misguided developer may link their kernel plugin against the user stubs.
My two cents: I have no problems with verbosity (especially in the age of auto-complete) if it makes the intention obvious. However one problem I run into with the ForKernel stuff is in modulemgr when I have functions called "sceKernelLoadModuleForPidForKernel" where "ForPid" denotes who I am loading for (in terms of context) and "ForKernel" denotes who is doing the loading. That's confusing and "ksceKernelLoadModuleForPid" seems cleaner.
in terms of the k
prefix, is it recommended that developers exporting functions follow suit? For example should I change it to ktaiHookForImport
?
I would advise developers to have the k
prefix for consistency, but of course not required. You bring a good point about auto-complete: it would be very effective using k
prefix for this also.
Another thing to consider is that some modules export for a ForDriver
and ForKernel
library with similar/same functionalities. Sometimes the NIDs are the same so it doesn't matter. But there might be (can't think of examples right now) functions whose NIDs are different but functionalities are the same.
I'm trying to not close your argument into a corner, but I think we'll need to find some sort of evidence to support that. In support/related, there are many kernel exports that are just wrappers for another export (be it ForKernel
or ForDriver
). How do we approach this?
I like the forkernel but maybe for auto completion is better to have a prefix I won't remove the sce And for the _ if there are no collisions I would remove it
Implemented in #99
Currently, some function names are prefixed with a '_' or two. The exact meaning of this prefixing is still debated.
Since they only convey information that is useless for homebrew developers, should we delete them all? From a homebrew developer point of view, adding an underscore to some functions but not to others is a annoyance.
In addition, the function names come from very different sources: it's currently inconsistent, and it would be very hard to fix the names to a chosen standard.
Do you agree with the suggestion of deleting all prefixed underscores from
db.json
?@yifanlu, @173210, @xyzz, @DaveeFTW