Changes between Version 15 and Version 16 of DiffFromUnix
- Timestamp:
- 2017-04-11T06:50:28Z (7 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
DiffFromUnix
v15 v16 1 1 = Design differences from UN*X and POSIX systems = 2 [[PageOutline(2-3)]] 2 3 3 == No `fork()`, no `exec()` == 4 == Processes == 5 6 === No `fork()`, no `exec()` === 4 7 5 8 In traditional UN*X, new processes are created by duplicating the resources of the current process via a call to `fork()`. Forking a process will, among other things, clone the current thread of that process. After `fork()`, both threads typically test whether they are the parent or the child instance. Very often, the child thread makes a call to `exec()` to load a new program. Calling `exec()` replaces the contents of the address space of the entire process with the new content of the loaded program. As can be seen, especially without heavy optimizations such as copy-on-write allocation of memory pages and non-duplicating variants of `fork()` such as `vfork()`, the procedure of spawning a new program is quite wasteful. This is the reason why UN*X standards introduced `posix_spawn()` which should be the way forward, but fork()/exec() will probably remain for backward compatibility (forever?) … … 7 10 In HelenOS, there is no `fork()` or `exec()` or any variant thereof. Programs are simply spawned by calling `task_spawn()`, which creates a separate new task for the loaded program and allows the caller to continue to run. Likewise, new threads and thread-like entities are created by calling `thread_create()` and `fibril_create()`. 8 11 9 == Running in background==12 === Running in background === 10 13 11 14 When you run a command in the shell, it starts the command and waits for it to terminate / return exit status. In UN*X a process that wants to return control to the parent shell and continue running in the background (typically a daemon) does a fork(), the parent immediately exits (thus returning exit status) and the child continues running. In HelenOS there is no `fork()`. Instead it is possible for a task to return status to the caller ''without exiting''. A HelenOS server usually initializes and registers itself with some naming service, then it calls `task_retval()` which returns status to the caller (effectively returning command line to the user) without terminating the task. After that the server usually enters the main message loop. 12 15 13 == No signals==16 === No signals === 14 17 15 18 To Be Improved. … … 17 20 Although HelenOS does not have the concept of signals, it is possible to pin-point their HelenOS equivalents for some of them. For example, SIGKILL is implemented as a dedicated system call. Some of the signals are replaced (or would be) by dedicated IPC calls. For example, SIGUSR1 is sometimes used to ask a server to reload its configuration. But that is actually abusing of the signals and it makes more sense to have a special (control) interface available through IPC where it is possible to explicitly say what the server shall do. As a matter of fact, similar concept can be traced to more signals, e.g. graceful termination (SIGTERM). 18 21 19 == Lexical dot-dot resolution == 22 23 == Filesystems == 24 25 === Lexical dot-dot resolution === 20 26 21 27 When the HelenOS file system layer sees a reference to '.' (current directory) or '..' (parent directory) in a file system path, it does not resolve it by traversing through the corresponding special directory entries, but rather makes use of its knowledge of the used absolute paths. Upon accepting the path from the user, HelenOS resolves references to '.' and '..' lexically by leaving out all occurrences of '.' and 'component/..' from the path. This represents a simplification of individual file system servers and allows file systems that do not explicitly understand the notion of the current and the parent directory in their directory entries to be supported. … … 44 50 }}} 45 51 46 == No serial terminals == 52 === No `open()` === 53 54 The [wiki:FilesystemAPITutorial filesystem API] can be described as a modernized, relativistic and de-conflated evolution of the legacy POSIX filesystem interface with consistent naming. Previously conflated APIs such as `open()` are divided into a series of independent operations like `vfs_lookup()`, `vfs_open()` and possibly `vfs_resize()`, `vfs_link()`. These operations work with file handles, making the entire API relativistic. This means there is no global filesystem root shared by all processes. Instead, each operation can be performed on any file for which the process has a handle (a handle does not need to be opened). 55 56 == Networking == 57 58 === No BSD sockets === 59 60 HelenOS doesn't use BSD sockets. Instead, it comes with its own sleek and modern [wiki:NetworkAPITutorial networking API]. 61 62 == Terminals, consoles and GUIs == 63 64 === No serial terminals === 47 65 48 66 In the world of UNIX-like operating systems command-line applications can make use of a pseudo-graphical UI via [n]curses or a similar library. This provides commands like move cursor, set color, etc. Conversely keyboard input (including some control keys like arrows, Page Up, etc) can be retrieved by the application. However only a dumb serial line / character device is assumed to connect the application to the console. … … 52 70 In HelenOS the application talks directly to the console via an IPC interface. 53 71 54 == No X==72 === No X === 55 73 56 74 Linux is already moving away from X and no, HelenOS won't have X. We have our own compositing display server, just as Linux will probably have in the near future. 57 75 58 == No legacy API burden == 76 77 == Miscellaneous == 78 79 === No legacy API burden === 59 80 60 81 POSIX still contains a lot of old interfaces that are sometimes known to be broken in certain ways. Many interfaces such as `ctime()` are not thread-safe so the standard defines a fixed thread-safe interface suffixed with `_r()`. Other interfaces are dangerous to use because they make potentially space-unconstrained modifications to a buffer, for example `gets()` or `strcpy()`. There are interfaces intended to fix some of these issues, for example `strncpy()`, but unfortunately they turn out to be dangerous or at least problematic to use just as the original interface was. Even though it comes with a limited compatibility library, HelenOS does not have to be compatible with all this brain-damaged and insecure stuff. The HelenOS native `libc` does not provide any of these (or it is a bug). Instead, it attempts to learn from the mistakes of others and provides new clean interfaces where applicable. 61 82 62 == Universal character set only==83 === Universal character set only === 63 84 64 85 HelenOS uses the Universal Character Set or UCS (as defined by ISO/IEC 10646) for representing characters throughout the system. This is in contrast to the common UNIX system where characters are encoded using ASCII or some language-specific extension thereof. 65 66 == No BSD sockets ==67 68 HelenOS doesn't use BSD sockets. Instead, it comes with its own sleek and modern [wiki:NetworkAPITutorial networking API].
