Though implementing fork() in a kernel is entirely distinct from using fork() in user space. Implementing fork() is mostly "just" manipulating a bunch of data structures the right way. Copy the right bytes and set the right values.
It's like how you can implement Java, C++, python, Haskell and any other (practical) language in C, despite C having no support for e.g. classes or lambdas. Or how humans can design and build combustion engines, despite us not having the capability to ingest gasoline in order to rotate an axle at 6000rpm ourselves.
Yeah, I get the difference in levels of abstraction. Still interesting, at least to me. Among other things, it limits how "thin" the POSIX emulation can be. So, for example, if I had a POSIXy super-CPU, an implementation of fork() in C, running on that CPU, could be rather thin. An implementation of fork() in Go seems like it'd necessarily have to be considerably thicker, as fork() is more foreign to Go.
But yes, I understand that this noodling has little to do with what the authors were going for, nor really with current reality.
I fail to see how the implementation of fork in C would be any thinner than an implementation of fork in Go. I expect the implementations would look very similar.
That sounds more like some kind of unusual “emulation layer” in user space than any “kernel”, and given your decision to use the host environment’s fork(), apparently one that just uses the host operating system’s (that’s what that “Super CPU” is, not a CPU at all but a full operating system) process model and everything associated with it, so you wouldn’t be able to emulate much.
