Talk:System call

Font

open,read,write and close, and fork,exec,exit and wait should all be in whatever truetype font we normally use to represent programs or functions. Can someone get around to this? I'm not leet to change the font. --Carbonrodney 12:08, 28 February 2007 (UTC)

dw, I learned. --Carbonrodney 12:12, 28 February 2007 (UTC)

category System calls

Do we need the Category:System calls ? `a5b (talk) 11:17, 28 September 2009 (UTC)

Proposed merger of Supervisor Call instruction into System call

User:Calaka proposed merger of Supervisor Call instruction into System call with the subject To me the sound like the same thing but otherwise leave as they are or maybe add a see also section. Ref here: http://www.answers.com/topic/supervisor-call.

Oppose - They are not the same thing. The Supervisor Call instruction simply causes an interrupt; it is up to the interrupt handler to decode the SVC number, determine the type of routine and dispatch it. Instruction like MME and SVC can be used as part of the implimentation of a System Call, but they are not themselves System Calls.

This is very different from, e.g., the Program Call instruction. PC and similar instructions actually perform the context switch and dispatch the proper routine without intervention from the operating system, although they do rely on the proper control blocks and registers having been initialized. Shmuel (Seymour J.) Metz Username:Chatul (talk) 06:43, 14 November 2010 (UTC)

Oppose - system call is for the general concept, Supervisor Call instruction is for a particular instruction that's used to implement it. (Shorter Guy Harris: "what he said.") Guy Harris (talk) 21:00, 17 November 2010 (UTC)

Strongly Oppose - PC, etcetera, are new to S/390, etcetera, and are apparently similar to competitive architecture implementations whereas SVC is historical, and is specific to the S/360 and successor architectures. In actual applications, SVC has proved to be faster than PC, although PC is less constrained, whereas SVC is architecturally constrained to 256 distinct functions (a few of which have been "extended"), with functions 0x00 on up to about 127 defined for IBM-supplied and supported functions, and with functions 0xFF on down to about 128 reserved for user-supplied and supported functions. SVC's implementation implicitly includes at least a first-level (SVC) interrupt handler, and possibly a second-level (SVC) interrupt handler with associated control blocks for saving of status, plus the possibility for a delayed return to the SVC invoker, or the immediate return to the SVC invoker. In the delayed return case, the OS supervisor's dispatcher is possibly involved, and may cause a task switch (which PC cannot and does not do). Finally, SVC allows for the possibility of the invoked function running disabled for interrupts (SVC Type 6 in MVS also Type 1 in pre-MVS). To merge SVC with PC or other similarly named functions would be a serious mistake and would not be true to history. — Preceding unsigned comment added by Peterh5322 (talk • contribs) 17:48, 31 May 2011‎ (UTC)

That's not exactly what's being discussed here - "system call" isn't an instruction named "System Call", it's a general concept - but if there were a page for the Program Call instruction, it shouldn't be merged here either. As per my comment, this page is for the general concept of a call that involves a transition from a less-privileged processor state to a more-privileged processor state; it sounds as if both SVC and PC are particular S/3x0 instructions that do the transition - SVC pretty much just does that, through a software interrupt, while it sounds as if PC does more. Guy Harris (talk) 20:40, 18 April 2012 (UTC)

Oppose - "Supervisor Call instruction" goes into a lot of IBM-specific detail that would be out of place in "system call", a more general article. Peter Flass (talk) 00:32, 10 September 2012 (UTC)

Oppose - Really? Is "sound like the same thing" a valid justification? The name of the planet "Uranus" can be pronounced as if it is a part of a person's body, not a heavenly body; should Uranus be merged with human anatomy? Sam Tomato (talk) 20:32, 30 April 2018 (UTC)

Multithreading models

Hey Peter Flass! Regarding your recent edit, I'd say that this description of the available multithreading models and associated mappings between user-level and kernel-level threads would fit much better into an article that deals with the threads themselves, while System call article should contain just a very brief summary of the pros and cons between various models. Thoughts? — Dsimic (talk | contribs) 05:20, 14 September 2014 (UTC)

(Actually, the multithreading stuff was originally contributed by Sidsaurb and subsequently edited by others, including 14.139.155.243 and Peter Flass.)

I agree - it's really describing threading models in general. It's relevant to system calls only in whether a blocking system call blocks only one thread (1:1 and, in most if not all cases, M:N) or blocks more than one thread (many:1 and possibly M:N) and, in a model other than 1:1, if it blocks only one thread, how that is made to happen. It's up to Thread (computing)#Models to describe the threading models. Guy Harris (talk) 07:34, 14 September 2014 (UTC)

Thank you for clarifying the way this content reached the article, I obviously haven't paid enough attention to the revision history. — Dsimic (talk | contribs) 07:40, 14 September 2014 (UTC)

Agree Peter Flass (talk) 10:36, 14 September 2014 (UTC)

Thanks. If everyone agrees, let's wait for comments from Sidsaurb before doing anything. — Dsimic (talk | contribs) 21:59, 14 September 2014 (UTC)

A related issue is that the existing text seems to violate WP:NPOV in that it assumes a binary kernel-user dichotomy. In some systems, e.g., Z/OS, there is privileged code that does not conform to the academic concept of a kernel. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:35, 18 November 2016 (UTC)

In what way does it not conform? Guy Harris (talk) 23:19, 18 November 2016 (UTC)

Starting with OS/360, IBM had a nucleus with a mixture of privileged and unprivileged code, SVC routines which were privileged and several programs that ran a key zero jobs. No clean layering there.

The DAT-off nucleus is the closest to a kernel the MVS has, but it doesn't do, e.g., dispatching. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:33, 2 December 2016 (UTC)

"Several programs that ran as key zero jobs" is somewhat like "several daemons that run as root" in UN*X or "several daemons that run with administrative privileges" in Windows NT and so on, so either that's not really disqualifying or there are a number of other OSes, probably discussed in the article, that also don't have a binary kernel-user dichotomy.

"a nucleus with a mixture of privileged and unprivileged code" - i.e., there's code in the nucleus that ran in problem state rather than supervisor state? Guy Harris (talk) 22:20, 2 December 2016 (UTC)

Unix programs that run as root are still subject to storage access controls and can't execute privileged instructions. That's very different from running in key zero supervisor mode. The analog to root in classic MVS is APF authorization.

More precisely, there's code in the Nucleus that runs in the state of the caller, e.g., TTR to MBBCCHHR conversion. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:12, 6 December 2016 (UTC)

So by "several programs that ran as key zero jobs" you meant "several programs that ran as key zero jobs in supervisor mode?"

And by "there's code in the Nucleus that runs in the state of the caller" you mean "the code runs in problem state if called from problem state and runs in supervisor state if called from supervisor state" (presumably meaning you call them with BAL/BALR, or something such as that, rather than an SVC)? Guy Harris (talk) 19:14, 6 December 2016 (UTC)

What about gates in the hardware architecture?

Some hardware architectures, e.g., GE 645, Intel iAPX 432, have provision in the architectures for calls through, e.g., access descriptors, gateway segments, that raise or lower the privilege level, or even cause a task switch. These are similar to the newer IBM instruction Program Call. Should System call say anything about those? Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:58, 19 February 2015 (UTC)

Yes, any mechanism that allows a transfer of control that raises privilege levels counts. (The GE 645 only had provisions for entering "master mode" through a procedure call; ring crossings were done mostly in software, by, when running in a given ring, marking the code segments for code in other rings inaccessible, so that a call to an entry in the gateway segment, or a return from inner-ring code to outer-ring code, gets an access violation trap. The trap handler would then change segment privileges and transfer control to the code in the other ring. The 6180 added hardware support for protection rings; see Schroeder and Salzer, A Hardware Architecture for Implementing Protection Rings.) — Preceding unsigned comment added by Guy Harris (talk • contribs) 21:26, 19 February 2015 (UTC)

References

Etymology of "system call"

Who first started using the term "system call"? The article should include this info. Pacerier (talk) 02:42, 20 January 2016 (UTC)

The library as an intermediary

The "library as an intermediary" section describes undocumented mechanisms, or at least mechanisms the typical application programmer does not use. In my opinion the internals of how a system works is more of the system side than the application side. By definition of what a system call mechanism is, the typical application programmer's view of how to interface with the operating system should be described, at least for a typical assembler programmer.

For example, for Windows, system calls are made by calls to DLLs. The internals of what the DLLs do are the system side, not the application side. Even an assembler program would typically call a DLL to call Windows. For other operating systems, an assembler programmer might use a machine instruction, such as "int" or "svc". Sam Tomato (talk) 20:52, 30 April 2018 (UTC)

On at least some Unix-like systems, an assembler programmer directly using a trap instruction to call a system service would be writing code not guaranteed to work on all versions of the operating system; the OS application binary interface is expressed in terms of procedure calls to routines in various (dynamic) shared libraries, not in terms of system call traps. In addition, many APIs requiring a privilege transition might not be implemented as simple wrappers around a system call trap; they might make one or more system calls that are not necessarily part of the system API. macOS (and other Darwin-based OSes from Apple) and Solaris are systems that work in this fashion. Guy Harris (talk) 23:13, 30 April 2018 (UTC)

The article should make this clear in some fashion; it should not imply that it is a general rule for operating systems that all APIs requiring a privilege transition are implemented as direct system calls or, for programming languages that don't provide a mechanism for making system calls inline, as calls to small wrappers making direct system calls. Guy Harris (talk) 23:13, 30 April 2018 (UTC)