I am curious about mechanism of Linux compatibility layer of FreeBSD and got some info below.
https://en.wikipedia.org/wiki/FreeBSD#Compatibility_layers_with_other_operating_systems
https://unix.stackexchange.com/questions/172038/what-allows-bsd-to-run-linux-binaries-but-not-vice-versa
The key difference between two OSes is difference of system calls.
And, I know Linux app and BSD app depend on different standard dynamic libraries (linux-gate.so.1 for example).
Is there anything else in the implementation?
The approach to being able to run Linux apps in FreeBSD is multi-faceted.
The parts of the strategy, as I understand it, are as follows:
Provide a system call layer that mimics as close as it can the Linux system call structure and semantics. In FreeBSD, this layer is called 'the linuxolator'
Install a set of vanilla pre-compiled Linux userland libraries. These libraries work because the linuxolator provides the right system calls that they depend on.
Install/provide/mount platform services that Linux userland libraries and apps expect. For example:
Mount a Linux-compatible procfs - linprocfs.
Install pre-compiled Linux apps and have them depend on these Linux userland libraries.
The Linux Apps call the Linux libraries which call the Linuxolator's Linux system calls which call the FreeBSD system calls.
Some functionality is available on Linux (udev, systemd, inotify(7), ...) but not on FreeBSD (and probably vice versa).
Some system calls have different flags. FreeBSD mmap(2) is not exactly the same as Linux mmap(2), etc...
Both are Unix systems, but the devil is in the details.
If you want to code in C an application for both OSes, try hard to follow POSIX.
Related
I wish to write a graphical tool with which one could configure and query information about a Linux system.
In order to achieve some independence from the underlying Linux distribution, I am planning to require that the target system uses systemd, and that the target system has the PackageKit console program installed.
With this, I will have excluded Slackware Linux, since it does not use systemd.
What other considerations should I have in mind when designing such a tool? With the use of an abstraction layer away from the package manager, and with the use of systemd, are there any other things that I would have to consider?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
I'm studying Operating Systems. I read Window have lots of system calls for manage windows and GUI components. I have read you can change the GUI manager of your Linux Operating System. Then does Linux have system calls for GUI managements? How GUI works in Linux?
I'll take x86 as an example as I am more aware of x86 stuff than ARM stuff. Also, I may get some information wrong as I've been doing some research on this question while answering. Feel free to correct me if I am wrong.
System booting
Some time ago, Linux used to boot with a legacy bootloader (GRUB legacy version). The GRUB bootloader would be started by the BIOS at 0x7c00 in RAM and then would read the kernel from the hard-disk. It would follow the multiboot specification. The multiboot specification mentions the state that the computer needs to be in before jumping to the kernel's entry point. The kernel would then launch a first process (init) that every process would be a child of.
Today, most Linux distributions boot with UEFI (with the option of legacy booting also available). A UEFI app is placed on the boot partition partionned as a GPT ESP (EFI System Partition). This EFI app is launched and then follows the Linux Boot Protocol to launch Linux. The init process was also replaced by systemd. Linux will thus launch systemd as the first process of the computer. Actually, as stated on the manpage for systemd:
systemd is usually not invoked directly by the user, but is
installed as the /sbin/init symlink and started during early
boot.
The process that will be started is thus /sbin/init but it is a symlink to systemd. The systemd process will then read several configuration files on the hard-disk called units. These units are often targets which specify several units to read. Targets are thus units which specify several units to read. At first systemd will read default.target which specifies several other units. Some of these other units will start some processes among which is the Display Manager (fancy terminology which means login prompt). Recently, Ubuntu starts the Gnome Display Manager (GDM) as the first displaying program (gdm.service unit). This program will start the X server before presenting the user login screen (https://en.wikipedia.org/wiki/X_display_manager).
When the display manager runs on the user's computer, it starts the X server before presenting the user the login screen, optionally repeating when the user logs out.
Once logged in, GDM will start several other binaries responsible to let you interact with the system (the actual desktop, a binary to gather input for this desktop, etc). All of these components depend on the X server to work properly.
The DRM
The X server is a user program which makes extensive use of the Direct Rendering Manager (DRM) of the Linux kernel. The DRM is a system call interface which is used to interact with graphics cards. When the DRM detects a graphics card, it exposes a file like /dev/dri/card0 which is a character device (http://manpages.ubuntu.com/manpages/bionic/man7/drm.7.html).
In earlier days, the kernel framework was solely used to provide raw hardware access to
priviledged user-space processes which implement all the hardware abstraction layers. But
more and more tasks were moved into the kernel. All these interfaces are based on ioctl(2)
commands on the DRM character device. The libdrm library provides wrappers for these
system-calls and many helpers to simplify the API.
When a GPU is detected, the DRM system loads a driver for the detected hardware type. Each
connected GPU is then presented to user-space via a character-device that is usually
available as /dev/dri/card0 and can be accessed with open(2) and close(2). However, it
still depends on the grapics driver which interfaces are available on these devices. If an
interface is not available, the syscalls will fail with EINVAL.
The ioctl call allows to have any number of operations on the /dev/dri/card0 file since it is a general call which includes a request argument which is simply an unsigned long. It also takes a variable amount of arguments (see https://man7.org/linux/man-pages/man2/ioctl.2.html).
The ioctl call thus allows hardware vendors (like NVIDIA, AMD, etc) to provide drivers for their cards with the general ioctl call used as a general interface between user mode and kernel mode.
OpenGL
There exists several 3D rendering APIs available (OpenGL, Direct3D). OpenGL is mostly a set of C headers and a convention. The convention says what a certain call should do. It is up to the hardware vendor to implement the convention for their own card. Mesa3D has been an attempt to create an open source implementation of OpenGL for certain graphics cards. It worked quite well for integrated Intel HD Graphics (since documentation is open) and AMD (since they cooperated and offered some insight into the workings of their cards), but not for NVIDIA (the Nouveau driver is mostly not working or slow).
When you program some OpenGL, you include the OpenGL headers and link with libraries provided by hardware vendors which provide the definitions of the functions in the headers. These definitions make use of the DRM and cooperate with the X server to show content on the screen.
I'm studying Operating Systems. I read Window have lots of system calls for manage windows and GUI components. I have read you can change the GUI manager of your Linux Operating System. Then does Linux have system calls for GUI managements? How GUI works in Linux?
System calls (provided by the kernel) are often buried (e.g. in some cases deliberately undocumented and proprietary) and should not be used. Almost everything you see are actually normal functions in dynamically linked libraries/shared libraries. This allows the kernel's system calls to be radically changed without breaking everything (because everything only depends on the dynamically linked libraries/shared libraries); and reduces the functionality needed in the kernel itself.
For an example; most of the "system calls for managing windows and GUI components" you think Windows has could (internally, inside the relevant DLL) just end up using a single "send_message()" system call (to tell a different process, the GUI, that you want to create a window or change its position or ...).
For Linux it's roughly similar. The kernel's system calls (which actually are documented, for no sane reason - it goes against the spirit of SYS-V specs and means badly written "linux executables" aren't compatible with other Unix clones like FreeBSD or Solaris or OSX) exist to use things like low level memory management and raw file IO and sockets; but (like Windows) the kernel's system calls are buried under layers of shared libraries, and those shared libraries (e.g. like Xlib, GLib, KWindowSystem, Qt, ...) just use "something" (file IO, pipes, sockets, ...) provided by kernel to talk to another process (display server, GUI, ..).
Linux and Windows fall under separate categories; Linux is just a kernel, i.e. the piece under the hood that gives us the basic functionality we expect to run programs, like threads, memory and process management, etc. Windows is a full operating system, including the user facing components and numerous system libraries. An apter comparison would be a specific Linux distro and Windows.
On that note, distros, as independent operating systems, obviously can have different implementations of any OS component. Some distros, like Arch, don't come with a GUI by default at all. That said, essentially the entire Linux ecosystem uses Xorg and/or Wayland; I would recommend looking into the implementation details of those two.
A Linux GUI has quite a few differences compared to Windows GUI. For example, the GUI is not considered to be a part of the operating system, but rather an external part of it; that means no syscalls (not embedded whatsoever in the OS). After all, like the previous answer says, Linux is a kernel, that means it's only something really basic (allows execution of programs, memory/threads management, processes management, but not really much more). Whatever comes next (GUI, for example) are added features using packages.
This allows, for example, installing a GUI on top of a minimal installation of any Linux distro (CentOS, for example), and that GUI can be the one you want (Gnome, KDE...).
I am fully aware of products like Wine and PlayOnLinux for using Windows application on Linux, but why am I unable to run .exe files on Linux? Is it because of something in the architecture of Windows operating systems that Linux doesn't use? Is it possible to create a linux distro or work with an existing one (Ubuntu, Mint, Debian, etc) to run .exe and .deb? If it is possible, what could be looked into and researched to be able to do so?
An executable file is a set of instructions the tells the program loader how to place the program in memory. An executable file can in turn reference shared libraries that are essentially executable files as well so the loading process is recursive.
First of all, the operating systems program loader needs to be able understand executable file format. This, the Linux loader does not do.
Second, any shared libraries referenced by the executable need to be available. Those libraries referenced in a windoze application are not going to be available on a linux system.
Even if you could get the past the first two hurdles, the operating systems would need to respond to system service calls in the same way. When you call an open file system service in Windows a linux system might interpret that as a close file system service call (or anything) (On Intel there are multiple ways of invoking system services).
Do
Linux system calls
Linux API
depend on
Linux distributions (e.g. Debian, Fedora, Ubuntu, Arch, Gentoo, ...), and/or
Linux kernel?
To answer your question about Linux System calls, you need to read man syscalls.
So yes, with different distributions, Linux kernel will change, hence the available system calls.
What do you mean by Linux API?
Linux Kernel's internal API
or the C ABI
Answer depends on the fact that is it a POSIX compliant call and if you are using a POSIX compliant system.
If your are using a POSIX call them most the system you have mentioned will support and work pretty much in the same way, since its a well defined standard that they follow them strictly.
There exists many system calls that are specific to certain systems, if you use such system calls or API then you your code is at risk since there is a good chance that it may or may not be available on the other systems.
More on POSIX here.
To answer the first part, the answer is mixture of yes and no, the yes part, all distributions of Linux, their core, the kernel comes from the main repository tree.
The no part, is that there is huge differences between Kernel 2.x, Kernel 3.x, likewise, Kernel 4.x, so the underlying implementation of the API governing aspects of the system, such as device drivers, for example, is different. For example, kernel module that is dependent on Kernel v3.x implementation, will not work under Kernel v2.x.
That is nonetheless to say, differing implementations can be backported to the older versions of the Kernel.
However, the system calls are relatively static and have not changed much. (see SysCalls)
Distributions, on the other hand, encompasses the Kernel and all libraries, notably GNU C library, which would have been recompiled as updates are made where applicable.
Provided the API behind those runtime libraries have not changed, then code that targets a version of library can be recompiled against a newer version of them runtime libraries.
I have read "system call APIs are for user-space access and
system APIs are for system space access". I am new to Linux OS concepts, I don't have any knowledge about the System API. Can anyone explain the difference between these two?
A system call is an explicit request to the kernel made via a software interrupt. It is the lowest level thing which talks to the Operating system. System call is when you call the kernel. System-calls are actually intended to be very low-level interfaces, you can say to a very specific functionality which your program cannot accomplish on its own.
Whereas a System API are used to invoke system call
Read system call and linux kernel wikipages first.
As Rahul Triparhi answered, system calls are the elementary operations, as seen from a user-mode application software. Use strace(1) to find out which syscalls are done by some program.
The system calls are well documented in the section 2 of the man pages (type first man man in a terminal on your Linux system). So read intro(2) and then syscalls(2).
Stricto sensu, syscalls have an interface, notably specified in ABI specifications like x86-64 ABI, defined at the lowest possible machine level - in terms of machine instructions and registers, etc... The functions in section 2 are tiny C wrappers above them. See also Linux Assembly HowTo
Please read also Advanced Linux Programming which explains quite well many of them.
BTW, I am not sure that "System API" has a well defined meaning, even if I guess what it could be. See also the several answers to this question.
Probably "System API" refers to the many functions standardized by POSIX, implemented in the POSIX C library such as GNU libc (but you could use some other libc on Linux, like MUSL libc, if you really wanted to). I am thinking of functions like dlopen (to dynamically load a plugin) or getaddrinfo(3) (to get information about some network things) etc... The Linux implementation (e.g. dlopen(3)) is providing a super-set of it.
More generally, the section 3 of man pages, see intro(3), is providing a lot of library functions (most of them built above system calls, so dlopen actually calls mmap(2) syscall, and getaddrinfo may use syscalls to connect to some server - see nsswitch.conf(5), etc...). But some library functions are probably not doing any syscall, like snprintf(3) or sqrt(3) or longjmp(3) .... (they are just doing internal computations without needing any additional kernel service).