This changes from kernel to kernel and you really should read a kernel book for the version of the os that you're interested in. But a few general comments... a few system calls may not be system calls. An example is getpid(), it may be possible for a process to obtain it's own pid without involving the kernel. The real system calls have C wrappers... there really is a write() function in the library for you to call. In a typical implementation, it will call a syscall() function with a first parameter which is the system call number. (But depending on the system call, it may need to do some work first.) These system call numbers are usually in a file called /usr/include/sys/syscall.h and that is how you can see the real system calls. syscall() is always written in assembler and it will usually invoke an instruction that behaves a lot like a hardware interrupt. It calls a kernel routine much like a disk interrupt would invoke a disk driver. The kernel, including drivers and the kernel's system call routine, operate in a higher mode than user code and the kernel has access to instructions that a user program cannot run. These almost always include instruction to read or write data from an alternate address space. The kernel would use this to read the buffer during a write(). But there isn't any need to put data in the user buffer during a write. When the system call in the kernel is finished, it invokes a special return instruction that goes back to the syscall() routine in user space. syscall() has a way to obtain a few integers from the kernel, usually because the kernel stored them in registers. This includes the return code, and errno. The syscall() routines stores these integers in a common place and returns the write() (or whatever) wrapper that the user called. The wrapper may have some work to do depending on the system call. Then it returns to the caller.

This is very general description, and again, you should read an internals book specific to your version of unix for more details.