Talk:System call

message: 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)
replies: text: dw, I learned. --Carbonrodney 12:12, 28 February 2007 (UTC)
thread_title:  Font 

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

message: 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)
replies: text: 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)
thread_title:  Proposed merger of [[Supervisor Call instruction]] into [[System call]] 

message: Some hardware architectures, e.g., GE 645And later versions, e.g., Honeywell 6180, DPS-8/M, 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)
replies: text: 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)
thread_title:  What about gates in the hardware architecture? 

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

message: 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)
replies: text: 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)

text: 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)
thread_title:  The library as an intermediary