Discussion: Standards for entries in db.json about vita-headers

[DaveeFTW]

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:

• wherever possible take inspiration from user mode equivalents and suffix ForKernel. e.g, sceIoOpen to sceIoOpenForKernel. We would not use the ForDriver suffix.

For new contributions:

• if we have an "official" name we will use it only for reference.
• names will begin with sce prefix, followed by a reasonable* name or abbreviation for the module it belongs to.
• names will be camelCaseStyle.

As such, all sce prefixes will be reserved by SDK.

• I'm not sure what reasonable is, maybe we should create a table? The obvious exception is using sceKernel when it comes to the various `ForKernel`` libraries.

[DaveeFTW]

We could do two prefixes:

• ksce for kernel functions
• sce for user functions

This would make it very clear that the developer is using the intended function.

[yifanlu]

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.

[173210]

There are some other symbols which have different prefixes such as vsh. We may make clear what prefixes are reserved by the SDK.

[d3m3vilurr]

how about just use k prefix or suffix for the kernel function?(like kSceIoOpen or sceIoOpenK)
ForKernel is too long suffix.

[DaveeFTW]

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.

[yifanlu]

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.

[yifanlu]

in terms of the k prefix, is it recommended that developers exporting functions follow suit? For example should I change it to ktaiHookForImport?

[DaveeFTW]

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.

[DaveeFTW]

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?

[frangarcj]

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

[yifanlu]

Implemented in #99