A kernel should not concern itself with “commands”, which are the province of a user interface shell. Rather, it should have system calls, and there is no ‘right’ number of system calls, but generally the fewer needed to provide the needed functionality the better. The only case where a kernel should even have “commands” is if it has a language REPL fundamentally built in, e.g. in the case of a Forth, and in this case there should be no difference between “commands” and system calls.
To be completely honest, you shouldn’t count commands implemented. Why? More commands does not make something better, and fewer commands does not make something worse. If a system can be more elegant through having a smaller set of primitive operations that can be utilized to do the same thing as a big, elaborate system, that very often is for the best.
Take Unix, for instance ─ traditionally Unix was all about simple but powerful operations and commands that could easily be composed with one another. Contrast this with, say, VMS, which was a big complex system with all kinds of ways of doing things. But that didn’t mean that VMS was better at all. If anything, Unix was superior in is simplicity and elegance.
This does not really look like an OS API but rather is just a collection of ‘commands’. For a kernel API I’d expect things like tasking calls, e.g. spawn a task, exit the current task, and if multitasking things like send a task a message, receive a message from another task, etc. Also, for a filesystem layer API I’d expect things like open a file, create a file, close a file, read a file, write to a file, etc. I don’t see anything like these here.
there is the open file, create file, delete file, create dir, delete dir commands. Which the app dev can use. The writing to a file will come in version BETA.
I don’t see open file anywhere, and command_createfile() makes no indication of taking, say, a file path or of returning a file descriptor or populating a file control block (as an alternative approach to using file descriptors).
I’m still mad at Adafruit (even though I buy products through them, largely because it’s quicker to buy Pimoroni products from them here in the US than to buy them directly from Pimoroni, which is based in the UK) for what they did to MicroPython in creating CircuitPython, and CircuitPython is far less sketchy than this ‘PikaPython’.