Hot answers tagged

52

It's due to the technical constraints of the time. The POSIX standard was created in the 1980s and referred to UNIX, which was born in the 1970. Several C compilers at that time were limited to identifiers that were 6 or 8 characters long, so that settled the standard for the length of variable and function names.


22

dr01 is right, but there's also another reason - usability. Back in the day, you didn't have something as comfortable as a keyboard to type on. If you were lucky, you had something akin to an old-school typewriter. If you were unlucky, you had to deal with systems that required actual physical work to operate (as in, it took a lot of force to press the ...


18

In addition to the other answers, I would like to point out that Unix was developed as a reaction to Multics, CTSS, and other contemporary operating systems, which were significantly more verbose about their naming conventions. You can get a feel for these OSes at http://www.multicians.org/devdoc.html. For example, ...


10

The kernel does job scheduling and provides system calls. When a process is running, the kernel schedules its runtime - especially it assigns a PID to it - such information is stored inside the kernel address space, in data structures (e.g. inside a task struct). Thus, when a process calls the getpid() system call, the kernel just has to look in the task ...


9

Check this Wikipedia link on Exec function and this link on Starting a process with the exec() calls e – An array of pointers to environment variables is explicitly passed to the new process image. The "e" suffix versions pass an environment to the program. An environment is just that—a kind of "context" for the program to operate in. For example, ...


8

Dennis Ritchie set himself a constraint with C that it wouldn't rely on any linker features that weren't also required by Fortran. Hence the 6 character limit on external names.


8

If you want to prevent disk writes as much as possible, you can do this with Laptop Mode. One of the features of laptop mode is to allow a disk to spin down and to prevent the kernel from writing to it until memory gets full or until a timeout occurs (or until the disk needs to spin up in order to read data from it). See also the Arch Wiki. You'll presumably ...


7

When a system call is executed, there is a privilege switch, i.e. the executed code is allowed to execute more instructions and access data forbidden to userland code. There is however no process context switch so the kernel code is still running in the calling process context. That means the kernel does not need to search which process is calling it, it ...


6

I would say that it is misleading to call getpid() a "linux system call". That gives the impression that it is a Linux-specific system call, which it isn't. Actually, getpid() and many other system calls are specified by POSIX, and you will find it implemented on both Linux and MacOS and on many other systems, with identical behaviour. The majority of ...


6

Because of how waitpid works. On a POSIX system, a signal (SIGCHLD) is delivered to a parent process when one of its child processes dies. At a high level, all waitpid is doing is blocking until a SIGCHLD signal is delivered for the process (or one of the processes) specified. You can't wait on arbitrary processes, because the SIGCHLD signal would never ...


6

It is difficult to do nontrivial things in a signal handler, since the rest of the program is in an unknown state. Most signal handlers just set a flag, which is later checked and handled elsewhere in the program. Reason for not restarting the system call automatically: Imagine an application which recieves data from a socket by the blocking and ...


4

In a single CPU system, there is a global variable that points to the proc structure of the running process or the current thread. The proc structure contains the process id. In a multi CPU system, there is either a similar pointer for every CPU or the MMU context is used to set up such a global variable for the syscall. int64_t getpid(void) { ...


3

The shell knows that ssh died and can reset the terminal. Tracing a bash shell while I kill a child ssh shows that it makes several ioctl() calls. --- SIGCHLD (Child exited) @ 0 (0) --- ioctl(255, TIOCSPGRP, [52631]) = 0 ioctl(0, TIOCGWINSZ, {ws_row=25, ws_col=147, ws_xpixel=902, ws_ypixel=329}) = 0 ioctl(0, TIOCSWINSZ, {ws_row=25, ws_col=147, ...


3

Mysql doesn't have a kernel module, therefore it runs in user mode. Perhaps what you are seeing is that mysql is using memory-mapped files instead of calling read/write. So, accessing a page of memory causes a read/write without using a syscall. Or, perhaps you called strace without "-f" to follow the child processes?


3

In Linux, you have strace: strace -f sh -c 'grep word1 file > file.txt' Here we use -f to tell strace to trace child process. In *BSD, you have dtruss (which use dtrace underlying): dtruss -f sh -c 'grep word1 file > file.txt' OSX has trace. Historical Unix systems have truss (Solaris, AIX, etc.).


2

You can use strace -p <PID> -f to trace child process that are created as a result of the fork(2), vfork(2) and clone(2) system calls. Hint: Using -p PID -f will attach all threads of the given PID if it is multi-threaded.


2

Of course, the fundamental puzzle here is that filesystem permission checks are based on the combination of (the effective UID and) the effective GID and the supplementary GIDs. So, from the point of view of file permissions checks, the effective GID is equivalent to the supplementary GIDs, which leads to the OP's question. (In passing: if we are talking ...


2

As @AndrewHenle commented, depending on the system to schedule your processes in a specific sequence is unsafe and unjustified. Even when the scheduling appears to be consistent (as in your case), there is nothing preventing the operating system's implementers from altering the scheduler's behavior. If order of operations between processes/threads is ...


2

OS X is a certified UNIX operating system, guaranteeing it implements the POSIX standard. Linux, while not a certified UNIX, also implements the POSIX standard. If you limit your API calls to things that are part of POSIX you should have consistent behavior between OS X and Linux. Aside from POSIX, the C standard library is also standardized and you ...


2

According to _syscall(2) man page the _syscall0 macro may be obsolete and requires #include <linux/unistd.h>; indeed Linux 4.x don't have it However, you might install musl-libc and use its _syscall function. And you could simply use the indirect syscall(2) in your user code. So your testing program would be #define _GNU_SOURCE /* See ...


2

Read more carefully close(2) and Advanced Linux Programming Your formulation is wrong: close is a system call (listed in syscalls(2) for Linux) by which the application tells the kernel to release a resource (not the other way round). You could use strace(1) to understand the system calls executed by some command or process. See also pthreads(7), ...


1

The fork() and vfork() syscalls are different. The fork() syscall generates two identical processes with separate memory. The vfork() syscall generates two processes that share the same memory. With vfork() the parent will wait for the child terminates. The parent inherites from the variables that the program is sharing. So after the child was called, all ...


1

According to http://www.di.uevora.pt/~lmr/syscalls.html, the suffixes indicate the type of arguments: l argn is specified as a list of arguments. v argv is specified as a vector (array of character pointers). e environment is specified as an array of character pointers. p user's PATH is searched for command, and command can be a shell ...


1

Most worrisome would be [EIO] A previously-uncommitted write(2) encountered an input/output error. so programs ideally should check the return value of close, especially for EIO. Writes would most often fail if a filesystem fills up, though ideally there would be monitoring or logrotation or such to catch that situation ...


1

I do not understand what you are really asking but answer is probably: There is supposed to be no difference between filesystems. Syscalls and VFS are filesystem-agnostic. POSIX standard defines most of what file operations do, as far as stat fields are concerned, thus defining when and how atime alike fields are updated. That said, filesystems have their ...


1

Each architecture defines an "ABI" (application binary interface) which basically says "first argument goes here, second goes here, third goes here... return value comes back here". You read the spec for the ABI, and then you use the order and size of the arguments of a function to determine which register they go in. See ...


1

As explained in the The Linux Kernel Module Programming Guide (5.2. Read and Write a /proc File), the kernel calls a function associated with the driver during the driver's initialization to read the data from userspace into the kernel. The echo program does not know anything special about the kernel; the kernel does all of the work. Further reading: How ...


1

To cause a kernel panic "attack" =): echo c > /proc/sysrq-trigger


1

"redirection" is a concept of the shell, and the details around it depend on which shell you are talking about. Though, one might say that the basis for redirection rests with the notion that programs have pre-opened input and output file descriptors when they start, which traces back to how the execve function works. Namely that the child process inherits ...


1

For redirection, I would assume this (redirection) is implemented by the shell replacing stdin (by input for < input) and stdout (by output for > output) using dup2() - open files for input and output in = open() out = open() dup2(in, 0) // replace input file with stdin dup2(out, 1) // replace output file with stdout close(in) ...



Only top voted, non community-wiki answers of a minimum length are eligible