Generally, systems provide a library or API that sits between normal programs and the operating system. On Unix-like systems, that API is usually part of an implementation of the C library (libc), such as glibc, that provides wrapper functions for the system calls.Functions like write(),read(),open().. are used to make system calls from a C program.Does it mean that if a java program has to make a system call then at the lowest level it has to call these C library functions ?If so, then how..???
If you really need to you can do that with the Java Native Interface (JNI).
Beware it is not for the feint of heart; the JVM usually can do what you want.
One use-case of JNI is using OpenSSL for crypto in Java; this used to be substantially faster when I tested it (it was nearly 10 years ago).
http://www3.ntu.edu.sg/home/ehchua/programming/java/JavaNativeInterface.html
I assume you don't want to know how to do it in Java since the question is not tagged as a java question.
So the libc is the right way to do it but, for information purposes, in linux, you can use the syscall function. The syscall function can use an Int 0x80 signal, a sysenter instruction or something else depending on the platform.
Introduction to System Calls in Linux
In Java, this is done using native Methods. These are methods declared with the native modifier and (similarly to abstract methods) no body, whose real implementation is written in a platform-dependent language, usually C.
Additional native method implementations may be runtime loaded using System.loadLibrary(String libraryName).
Related
I am interested in programming my own OS from scratch(in C).
However, every tutorial I encounter has made a message print on the screen by writing directly to the VDU. Why can't I use standard library functions while writing my OS? I don't have much problem in writing directly to the VDU. However, it sometimes makes my mind utterly confused(especially in large programs).
Are the library functions not converted into the same low-level code as the functions created by us?
This is a kind of chicken-and-egg problem: Standard library functions use OS functions to print to the screen (deep down there, someone actually needs to write directly to the hardware).
Without an OS (because you just start writing one) this will not work. The standard library you want to use will need to be written specifically for and together with your OS.
Is it possible to run a written code or written library that only uses initial c libraries, on every platform?
For example:
Windows,
ARM Microprocessors,
PIC microprocessors,
They have their compilers seperately and this difference is not important for me, I can compile in different compilers for need. But do I have to change code totally or partially to run on this platforms?
Note: For libraries, I will just use default c libraries.
It depends. If your library use only standard C and the multiplatform you are about to port has a compiler compatiable to standard C, you can always write the library code. But if your library have to call native API of each platform, you have to encapsulate these code seperately.
In embedded systems you will need to implement certain functions that the operating system gives you (like _sbrk, _read, etc.) for standard library functions like malloc and printf.
If you take care of that I don't see a reason for your code not to work so long as you take GREAT CARE in how you write it. By GREAT CARE, I mean be very careful with floating points, processor word size and any other things that are not common between your desired targets.
Short answer: possible, but not easy.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
I understand how a system call work in C with Linux. I want to know whether each programming language would have its own separate system library to communicate with the kernel.
If yes should every programming language have its own system library
to work with the kernel?
If No then how does a system call in another programming language work
in linux?
On AMD64 Linux system calls are accomplished by loading the appropriate registers and executing the syscall function. On other architectures this is of course different.
Languages other than C must either make a foreign call to the C functions that make the system calls (which is usually easier and hence common), or make the system calls using the appropriate processor instructions as C does.
System calls are a mechanism to execute kernel resident functions from user space.
The big picture view is that a system call is wrapped up in a user space function call, which accepts certain arguments from the user. These arguments are packed up into a structure, along with a code that indicates which kernel resident function to execute. The code then executes a CPU instruction which causes it's privilege level to rise to that of the kernel, while simultaneously executing a path of code that is now inside the kernel. This is called entering the kernel. This code inside the kernel has access to the data structure that was assembled for the system call. It locates the target code, sets up the arguments for the code from the structure, and makes the call. It collects the return code and arranges for it to be returned to the user space by traversing the path in reverse.
There are other things that happen along the way, like address space switching etc., but this is pretty much what happens conceptually.
Here are some specific details.
Since C is pretty much the OS lingua-franca in the 21st century (in the sense that most mainstream operating systems are written mainly in C), many programming language implementations provide ways to call C code. For example, Java has JNI, and both the Python and Ruby reference implementations (CPython and CRuby) provide the ability to create C extension modules, etc.
Most mainstream operating systems (including Linux) typically expose one or more low-level C APIs for doing things like interfacing directly with devices, spawning processes, etc. Higher level languages can wrap these system calls and make them available at the language-level to the programmer.
In the Intel architecture any call into kernel-mode functionality involves an interrupt with some parameters (the system call number and other arguments in linux). If any programming language wants to utilize this it has to provide a construct which can be compiled into the right assembly (int 80 for example).
C and C++ provide this. Other languages compiling into native code can also be made to provide this. It is easier in general to call into C/C++ functionality by some means of RPC/COM calls.
Most languages have some means to invoke C function calls underneath commonly referred to as Foreign Function Interface. I've listed few I've come across:
Java - JNI
Python, Ruby, Perl, TCL - have extensions for directly calling native C code. Python also provides `ctypes`
Microsoft's CLR - P/Invoke a mechanism to invoke native platform code
First of all system calls use assembly to call the kernel - the language that the CPU understands. C is compiled to assembly. The system call on x86 is done with either int 0x80 or sysenter - both are assembly instructions executed by the CPU. The kernel itself is also compiled code. You have two types of languages compiled and interpreted.
The compiled languages are compiled to assembly - they can have a layer of own code in the language itself, kind of glue, that calls a c library with the syscall implementation or they can have own implementation of syscalls that compiles to assembly.
The interpreted languages are compiled code interpreter written in random language but compiled to something that runs on the CPU - they have the same two options, but in the interpreter - not in the byte code, not in the script code.
Is there a C library available for operations such as file operations, getting system information and the like which is generic, which can be used when compiled in different platforms and which behaves in a similar way?
Edit: Something like Java or .NET platform abstracting the hardware.
Have you tried the standard library? It should be implemented on any system that has an ISO compliant C runtime.
Yes; the ISO Standard C library. It may not cover all the functionality you want, but that is exactly because it is generic, and as such is also lowest common denominator. It only supports features that can reasonably be expected to exist on most hardware, including embedded systems.
The way to approach this is perhaps to specify the range of target platforms you need to support, and then the application domains (e.g. GUI, networking, multi-threading, image processing, file handling etc.), and then select the individual cross-platform libraries that suit your needs. There is probably no one library to fulfil all your needs, and in some cases no common library at all.
That said, you will always be better served in this respect by embracing C++ where you can use any C library as well as C++ libraries. Not only is the C++ standard library larger, but libraries such as Boost, wxWidgets, ACE cover a broader domain spectrum too. Another approach is to use a cross-platform language such as Java, which solves the problem by abstracting the hardware to a virtual machine. Similarly .NET/Mono and C# may provide a solution for suitably limited set of target platforms.
Added following comment:
Hardware abstraction in a real-machine targeted language (as opposed to a VM language such as Java or CLR based languages) is provided by the operating system, so what you perhaps need is a common operating system API. POSIX is probably the closest you will get to that, being supported on Linux, Unix, OSX (which is Unix), QNX, VxWorks, BeOS and many others; but not importantly Windows. One way of using POSIX on Windows is to use Cygwin. Another is to use a VM to host a POSIX OS such as Linux.
For anything not found in the standard library, GLib is a good first place to look along with other libraries built to interact with it. It offers for example threads, mutexes and IPC that you won't be able to write portably using plain standard libraries, and you can use many more GNU libraries that follow the same conventions up to a full GUI in GTK+. GLib supports the usual popular operating systems.
If the C standard library is not sufficient for your needs, a minimal hyperportable subset of POSIX might be the target you want to code to. For example, the main non-POSIX operating system Windows still has a number of functions with the same names as POSIX functions which behave reasonably closely - open, read, write, etc.
Documenting what exactly a "hyperportable subset of POSIX" includes, and which non-POSIX operating systems would conform to such a subset, is a moderately difficult task, which would be quite useful in and of itself for the sake of avoiding the plague of "MyCompanyName portable runtime" products which appear again and again every few years and unnecessarily bloat popular software like Firefox and Apache.
If you need facilities beyond what the Standard C library provides, take a look at the Apache Portable Runtime (APR). You should also review whether POSIX provides the functionality you are after, though that comes with its own bag of worms.
If you want to get into graphics and the like, then you are into a different world - GTK, Glib and Qt spring to mind, though I've not used any of them.
There are multiple sections in the manpages. Two of them are:
2 Unix and C system calls
3 C Library routines for C programs
For example there is getmntinfo(3) and getfsstat(2), both look like they do the same thing. When should one use which and what is the difference?
System calls are operating system functions, like on UNIX, the malloc() function is built on top of the sbrk() system call (for resizing process memory space).
Libraries are just application code that's not part of the operating system and will often be available on more than one OS. They're basically the same as function calls within your own program.
The line can be a little blurry but just view system calls as kernel-level functionality.
Libraries of common functions are built on top of the system call interface, but applications are free to use both.
System calls are like authentication keys which have the access to use kernel resources.
Above image is from Advanced Linux programming and helps to understand how the user apps interact with kernel.
System calls are the interface between user-level code and the kernel. C Library routines are library calls like any other, they just happen to be really commonly provided (pretty much universally). A lot of standard library routines are wrappers (thin or otherwise) around system calls, which does tend to blur the line a bit.
As to which one to use, as a general rule, use the one that best suits your needs.
The calls described in section 2 of the manual are all relatively thin wrappers around actual calls to system services that trap to the kernel. The C standard library routines described in section 3 of the manual are client-side library functions that may or may not actually use system calls.
This posting has a description of system calls and trapping to the kernel (in a slightly different context) and explains the underlying mechanism behind system calls with some references.
As a general rule, you should always use the C library version. They often have wrappers that handle esoteric things like restarts on a signal (if you have requested that). This is especially true if you have already linked with the library. All rules have reasons to be broken. Reasons to use the direct calls,
You want to be libc agnostic; Maybe with an installer. Such code could run on Android (bionic), uClibc, and more traditional glibc/eglibc systems, regardless of the library used. Also, dynamic loading with wrappers to make a run-time glibc/bionic layer allowing a dual Android/Linux binary.
You need extreme performance. Although this is probably rare and most likely misguided. Probably rethinking the problem will give better performance benefits and not calling the system is often a performance win, which the libc can occasionally do.
You are writing some initramfs or init code without a library; to create a smaller image or boot faster.
You are testing a new kernel/platform and don't want to complicate life with a full blown file system; very similar to the initramfs.
You wish to do something very quickly on program startup, but eventually want to use the libc routines.
To avoid a known bug in the libc.
The functionality is not available through libc.
Sorry, most of the examples are Linux specific, but the rationals should apply to other Unix variants. The last item is quite common when new features are introduced into a kernel. For example when kqueue or epoll where first introduced, there was no libc to support them. This may also happen if the system has an older library, but a newer kernel and you wish to use this functionality.
If your process hasn't used the libc, then most likely something in the system will have. By coding your own variants, you can negate the cache by providing two paths to the same end goal. Also, Unix
will share the code pages between processes. Generally there is no reason not to use the libc version.
Other answers have already done a stellar job on the difference between libc and system calls.