Different ways to invoke system calls - c

Question

In some code, I can see system call are invoked in a strange way, take sched_yield as an example:
#define __NR_sys_sched_yield __NR_sched_yield
inline _syscall0(void, sys_sched_yield);
And then we can use sys_sched_yield().
I'm curious what's the difference between using sched_yield directly and this way.
In src/include/asm/unistd, _syscall0 is defined:
#define _syscall0(type,name) \
type name(void) \
{ \
long __res; \
__asm__ volatile ("int $0x80" \
: "=a" (__res) \
: "0" (__NR_##name)); \
__syscall_return(type,__res); \
}

Answer 1

Presumably that's for systems where sched_yieldmight not be available.
As for differences, sched_yield returns -1 on error and sets ERRNO while this implementation presumably returns the raw value from the kernel. Can't tell for sure since you haven't provided definition of _syscall0 which must be a macro.

Answer 2

This is linux which uses glibc. BSD has a sched_yield but has its own libc.
This isn't strange. The syscall0 macro issues an assembler int 0x80 instruction and the syscall number is in the rax register [x86 architecture]. This is the standard syscall interface for linux. Under the hood, all linux glibc functions that are syscall wrappers will do this [or use the more modern sysenter/sysexit x86 instruction pairings]
glibc has a tendency to "usurp" syscalls in its wrapper functions and add stuff around them. For example, when you call fork, it [ultimately] calls __libc_fork which does a huge amount of extra stuff related to threads and file closure, etc.
Generally, glibc makes good choices. But, sometimes highly experienced linux application programmers want the raw syscall behavior, particularly if they're writing system utilities or programs/libraries that must have close interaction with the kernel, device drivers, or device hardware.
Actually, __libc_fork doesn't invoke the fork syscall, it invokes the clone syscall, which is a [harder to use] superset of fork. But, the plain old fork syscall still exists. So, if you want that, you need the macro stuff--and I'll bet there's a sys_fork definition somewhere.
On the other hand, glibc might implement sched_yield ala POSIX as a nop returning -1 and setting errno to ENOSYS. I just checked latest glibc source and I couldn't find the "real" implementation, except for mach. It probably does do the real thing, I just couldn't find it.
Sometimes, linux has a syscall, but glibc doesn't want to support it, or they consider it to be too dangerous for an application programmer, so they leave out the wrapper function. So, the macros are a way to "end around" glibc.
The probable reason for glibc implementing sched_yield as a nop, posix aside, is they consider it "bad" and probably tell you to use nanosleep instead. I've used both and they are not the same, depending on your use case and desired effect.
Sometimes, you need to do the raw, inline syscall. For example, the ELF loader [every system that supports ELF binaries must have one and linux's is ld-linux.so] is invoked by the kernel to load an ELF binary. It must operate before glibc.so is available, because it is what actually links in glibc.so, the ELF loader must have some builtin syscalls for open and read
Also, most systems have a syscall library function that takes a variable number of arguments. You could implement:
#define my_sched_yield() syscall(__NR_sched_yield)
#define my_read(_fd,_buf,_len) syscall(__NR_read,_fd,_buf,_len)
This function handles the kernel's syscall return value/error and sets errno. That's what the __syscall_return macro had to do.
The __NR_* prefix is what linux uses, but other systems have AUE_* or SYS_*