C library system-call wrappers, or the lack thereof

Re:C library system-call wrappers, or the lack thereof by userbinator on Tuesday November 13, 2018 @10:41PM (#18447283)

I'm curious what led to Linux (and it seems the other Unices) adopting the "double indirection" strategy of having a separate wrapper/stub function for system calls vs. the approach common in the MS-DOS world where the compiler would directly embed e.g. INT 21H instructions and generate the code to put parameters into registers itself. It's a small inefficiency, but still seems a bit wasteful nonetheless.

[ Parent | on HN ]

Re:C library system-call wrappers, or the lack thereof by skissane on Wednesday November 14, 2018 @12:47AM (#18447792)

When you write C code on MS-DOS, you usually don't directly call INT 21h. Instead you call fopen(),printf(), etc, which are library calls which call INT 21h in their implementation. As well as standard C functions, there are also C functions for MS-DOS specific services, e.g. chdrive(), findfirst(), etc.

Even when you want to call some INT 21h service which doesn't have a C function, it is more common to use interrupt functions like int86() or intdos() than to use inline assembly. (Or something like __dpmi_int from 32-bit code, such as DJGPP)

So, I don't think MS-DOS is as different from Linux/Unix as you think. High-level language code on MS-DOS (whether in C or Pascal or BASIC or whatever) usually doesn't directly invoke INT 21h, it goes through higher-level libraries / wrapper functions. Only software written in assembly tends to invoke INT 21h directly.

[ Parent | on HN ]

Re:C library system-call wrappers, or the lack thereof by pdkl95 on Wednesday November 14, 2018 @11:17AM (#18450988)

> Only software written in assembly tends to invoke INT 21h directly.

Or anybody that wasn't satisfied with the high-level libraries. We just looked up the functionality[2] we needed in Ralf Brown's list[1].

[1] http://www.ctyme.com/rbrown.htm (INT 21h http://www.ctyme.com/intr/int-21.htm )

[2] http://www.ctyme.com/intr/rb-0250.htm

[ Parent | on HN ]

Re:C library system-call wrappers, or the lack thereof by pcwalton on Wednesday November 14, 2018 @01:31AM (#18447970)

For one, sometimes you want to transparently migrate kernel functionality to userland. Moving gettimeofday from a syscall to the vDSO comes to mind.

[ Parent | on HN ]

Re:C library system-call wrappers, or the lack thereof by tacostakohashi on Tuesday November 13, 2018 @10:50PM (#18447321)

There's nothing stopping the wrapper function from being inlined (as it commonly is for some compiler + libc combinations), with all the usual tradeoffs for code size and ease of debugging.

[ Parent | on HN ]

Re:C library system-call wrappers, or the lack thereof by megous on Wednesday November 14, 2018 @07:11AM (#18449260)

It doesn't happen, unless you compile C library with LTO. I'm yet to succeed in doing that for my musl C mipsel target.

[ Parent | on HN ]

Re:C library system-call wrappers, or the lack thereof by JdeBP on Wednesday November 14, 2018 @12:36AM (#18447755)

Inlining isn't the answer here. userbinator and you are missing out on more than a decade of IBM/Microsoft operating system evolution, with the invention of high-level-language-callable kernel APIs in the likes of DOSCALLS.DLL and NTDLL.DLL in the 1980s.

[ Parent | on HN ]