He seems to be noting a difference between the kernel itself, and the rest of the operating system, the user-space constructs built on top of the kernel.
When you shut down the system with
/sbin/reboot or equivalent (which in turn calls systemd or some init scripts or something), it does more than just ask the kernel to shut down. The user-space tools are the ones that do almost all the cleanup, like unmounting filesystems, sending
SIGTERM to other processes ask them to shut down, etc.
If, instead, you go and call the
reboot() system call as root directly, then none of that cleanup happens, the kernel just does what it's told to do and shuts down right away (possibly restarting or powering down the machine). The man page notes that
reboot() doesn't even do the equivalent of
sync(), so it doesn't even do the kinds of cleanup that could be done within the kernel (where the filesystem drivers and I/O buffers reside.)
As an example from the man page:
(RB_AUTOBOOT, 0x1234567). The message "Restarting system." is
printed, and a default restart is performed immediately. If
not preceded by a sync(2), data will be lost.
Does system call
reboot() reboot the OS or kernel?
It asks the kernel to shut down or reboot, the OS goes down with it.
reboot reboot the OS but not the kernel?
It asks user-space processes to shut down, does other cleanup, and only then asks the kernel to shut down or reboot.
reboot() system call has a mode (
LINUX_REBOOT_CMD_RESTART2) that is described as "using a command string". However, it doesn't mean a user-mode command, but one internal to the kernel, and one that isn't even used on x86.
Note that while we're considering the distinction between the kernel and the OS-on-top-of-the-kernel, you could in principle reboot just the OS but keep the kernel running. You'd need to clean up everything set up by the userspace and kill other userspace processes, then restart
init to bring everything back up again instead of asking the kernel to reboot. That might not be very useful though, and it would be hard to reliably reset all state left in the kernel (you'd need to manually reset all network interfaces, clean up iptables rules, reset RAID and loop devices, etc. etc. There's a good chance of missing something that might then bite back afterwards.)