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 7 years ago.
Improve this question
Unix Operating System Picture
The picture provided is a sketh of a Unix operating system.
I'm not sure how the Unix OS works and these are some questions I had about it.
What is the overall functionalitiy of each of the layers labeled by numbers and the interfaces between the adjacent layers?
What is the purpose of organizing the components like this?
How would each of these layers differ from the OS of an android or IOS (mobile OS)
Thanks!
Userspace
The two top layer (the one called "the users"), plus the one labeled (1), are the userspace.
A UNIX process can't exist outside userspace.
Layer (1) is sometimes refered as "shell" layer.
It's not always clear what is or is not is shell layer. For short, we can consider this as the "system" part of userspace (by opposition to end-user applications). Typically, think of the command line utilities like cp, rm, mv, ln, ls, etc.
userspace provides memory isolation between process (one process can't write unexpectedly in other processes memory space).
Also, a program in userspace runs under a user identity, which provides him permissions to manipulate some resources in the system. An exemple is : you have a file that you owns in your home directory, which permission are -r-------- (readonly, only for the owner).
No other (unpriviledged) user in the system will be able to display its content, since any command they run inherit their identity and permissions.
Kernel
The layer 2 is the kernel. It is a very priviledged piece of code that is responsible to provide the features needed to acheive the userspace.
It is also the first piece of the system that is loaded into memory and then executed at boot time (just after the firmware bootloader).
It initialise the CPU and motherboard devices, and notably sets up the Memory Management Unit of modern processor. Momery isolation of processes relies on MMU operation mode.
The kernel is responsible to manage resources allocation (memory, files on hard disk, etc). Also responsible to kill a process that makes illegal accesses (for instance, outside its allocated memory space).
Why two layer ?
Beyond the technical justification presented above, there is another strong reason to have make this choice.
This layer concept comes from the early UNIX systems, and it is a core concept of all modern OSes (NB : the term Operating System, sometimes refers to the kernel only).
Indeed, by the time, they was no way to port a software to another computer model, furthermore if not designed by the same manufacturer.
The kernel was introduced to ease the port of software : when receiving a new computer model, Bell Labs had to make the effort to port the kernel, and the C compiler to this new machine, maybe some tweaks in system libraries.
But when this port was acheived, all other userspace software could be recompiled and executed on the new machine.
Also, it allows a same C code to be used (theorically) on different kernel implementation.
For instance, many of the tools you can find under linux are also usable under FreeBSD.
I don't mean a clone of the tools, i mean the same source code, compiled for the right target system.
Those comment are cleary not exhaustive, it's a hugely vast topic, but I hope it helps for pathfinding :)
Concrete instance :
basically GNU is a collection of system tools (a shell)
in a GNU/ Linux system GNU runs on a Linux kernel
NB : paradoxally, GNU is older than Linux
EDIT
I don't know for iOS but android is, basically a Linux system.
So it implements this layer concept, with a kernel and a userspace.
Anyway, despite it is based on Linux kernel, not on "vanilla" version, but a version highly tweaked by google developers.
The shell is also highly specific for the base distribution form google (AOSP) but theorically, GNU tools can be installed.
Related
I am working on one project which is a standalone javafx application. It will run 24*7*365 days continuously.
So, i have a question in mind.
which things we need to consider for running this application smoothly and with high performance for 24*7*365?
Please guides me sir, regarding it.
Details for used things are as follows for Reference :-
Used java version :- 1.8.0_121
Available Ram :- 2GB
Allocated Memory for application :- -Xmx1524M
Hardware Configuration :- Processor - Intel Atom CPUD425# 1.80GHz x 2
OS :- 32 Bit Fedora 15
I will probably state the obvious here, but OutOfMemory errors are the main thing you should worry about. A small glitch in your code/program could make your app die fast or run extremely slow under memory pressure.
I would say that you need to enable garbage collection logs and monitor those. Also is there a way for a javafx app to actually use another instance if the current one is facing issues? There are tools for that under different apps, but not sure about javafx... I mean can you automatically shut down (and collect heap data) the current running application and automatically start a new one (so that later you can analyze what actually happened)? It might not be feasible, and if it's not, you should have enough stress tests before you actually lunch it into production.
One thing you should check first is whether your system suffers from the notorious memory problems that some Linux graphics drivers have. See for example my answer to this question here on SO:
Javafx growing memory usage when drawing image
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm really curious right now. I'm a Python programmer, and this question just boggled me: You write an OS. How do you run it? It has to be run somehow, and that way is within another OS?
How can an application run without being in an OS? How do you tell the computer to run, say, C, and execute these commands to the screen, if it doesn't have an OS to run in?
Does it have to do with a UNIX kernel? If so, what is a unix kernel, or a kernel in general?
I'm sure OSes are more complicated than that, but how does it work? It would be really brilliant to know this!
Thanks.
You can indeed write a program without an OS. Indeed, on your PC there is already a program that runs without an OS before your OS boots up. There are two in fact. The first is your BIOS.
The IBM PC architecture is one of a family of architectures that employs BIOSes to start up the computer. Not all architectures have BIOSes. The iPhone for example boots directly into a bootloader. In fact, most "modern" architectures don't have BIOSes but boot directly into a bootloader. It's actually conceptually simpler this way.
The fact that PCs need BIOSes is merely a historical legacy. The original IBM BIOS was in fact a basic bootloader for loading DOS. Modern BIOSes are still bootloaders.. that load bootloaders.
Most PC BIOSes are proprietary. They allow manufacturers to initialize custom/proprietary hardware before passing control to bootloaders. This makes it possible to write bootloaders without having to worry about weather the OS image is on a flash drive, a USB thumbdrive, an SD card, a magnetic disk, on DVD etc. The boot loader simply sees a disk that have been initialized by the BIOS.
The next stage of boot up is the bootloader. The reason why the IBM PC architecture requires a bootloader is that the BIOS is usually designed to set up the CPU to run DOS. Modern OSes require the CPU to be configured slightly differently. Also, modern OS kernels (a kernel is the actual core executable code of the OS doing things like manage memory, cpu etc) tend to be large beasts, often larger than 4MB in size which is much larger than what most BIOSes are designed to load. So the BIOS loads a small bootloader which in turn loads the actual OS. Again, this is only necessary due to decisions made by IBM in the 1980s when they designed the original PC architecture. Modern archictectures like the iPhone or PS3 don't do this. They boot directly into the bootloader.
The bootloader is necessary to solve the chicken and egg problem: to load the OS you need to read from disk. To read from disk you need to use a device driver which is loaded by the OS. To break this circular dependency people write bootloaders which are basically very simple OSes that is designed to run only one program (the OS) and understand how to read from disks (or SD card, or the network etc.).
Which brings us to the part that answers your question. If you've written an OS, how do you load it? You load it by configuring your bootloader. Windows comes with a bootloader that's not too flexible. It understands how to load Windows but that's about it. You can install open source bootloaders like Grub or Burg which understand how to load other OSes as well.
The fundamental concepts involved in booting a machine is actually simple. It's the details that's scary. But if you're really interested in how OSes work learning it is very rewarding in the end. Also, if you're interested in this stuff I'd suggest looking around at other architectures apart from the IBM PC like Mac hardware which uses EFI instead of a traditional BIOS or Linksys routers which boot into Linux directly from a bootloader or embedded platforms like Arduinos that run a single program you compile directly on the CPU without an OS.
You need an OS to do things like virtualize memory and arbitrate access to the hardware. Because the OS has full access to things like memory and the hardware, it doesn't need an OS to run. The services that most programs get from an OS, the OS itself either has to provide itself or has to get from the hardware.
What runs any software is some kind of a CPU, a piece of electronic circuitry, hardware.
Whether the software is an OS or some other kind of program, the CPU doesn't care. It just runs it so long as it is possible (e.g. until said software causes an irrecoverable error forcing the CPU to enter some odd state or simply reset).
When powered on, the CPU starts executing whatever code it finds at a certain location in memory. That location can be either hardwired in the CPU or configured by external to the CPU circuitry or even programmed by software. Which one it is depends on the CPU and how the entire device is designed.
Not all programs need an OS to run on a CPU. An OS is a good example of such a program. If every OS needed another OS how would you stop this infinite recursion? :) But it's not the only one.
Many electronic devices, especially very simple ones like a digital clock, don't have any OS in them.
About the only time an OS runs atop of another OS, is when you have virtualization. But I'm not going to go there in this answer.
An OS is only needed either for its basic functions like scheduling, thread/process synchronization, memory allocation, etc or to do all or most of device I/O itself and hide the hardware peculiarities from programs running in the OS, IOW, to allow portable programs. You write print 123 in Python and it prints 123 everywhere, in any OS with which Python is compatible (=for which it is available), irrespective of the display, its resolution and many other differences that can be there on different computers and in different OSes. If general-purpose OSes had not provided some common functionality (and some more or less common API for it) such as console and file I/O and memory management, Python would not have been available for them and those OSes would not have been general-purpose in the first place.
An OS kernel is the core of an OS. It does most of the low-level and dirty work, dealing with:
interrupt handling
thread/process scheduling and synchronization
memory management
things alike
Sometimes that's enough of OS functionality and in such a case there isn't any difference between an OS and a kernel, they are the same thing here.
If, OTOH, more stuff is needed, e.g. much flexibility, support for different devices, some code to manage all that and a bunch of special drivers for file system, for network and TCP/IP stack, etc, then a simple (perhaps, only relatively simple) kernel alone isn't sufficient, there needs to be more stuff around it and that's where you start differentiating between an OS and a kernel and arrive at OS = kernel + extras. The text editor you're using, even if it came with your OS, is not quite one of those extras, it's a regular program, which needed not to be bundled with the OS, but for convenience it could be.
UNIX is one example of an OS. There are many more, most notably Linux and Windows.
You should get yourself some book on computer architecture and organization to learn how computers work in general. What it is inside there, how it's put together, what's happening under the hood, etc.
I am a newbie with Xen.I want to know how does Xen work.
It's really a puzzle when facing the code and I don't know where to start.
Are there some easy articles for me?
Since you mention looking at the code, I assume you want to understand the technical details of Xen and not just merely how to start a VM.
As with all problems, start with something simple and then work your way up. Some pointers:
Be sure to have the prerequisite experience under your belt. In particular, strong C and Linux affinity, but also x86 paging and virtualized memory workings.
Make sure you have a sound grasp of the general Xen architecture. For instance, paravirtualized versus hardware-supported virtualization, the special role of the management domain (Dom0) compared to unprivileged domains (DomU), etc.
Investigate the the Xen components running in Dom0:
The Xen control library (libxc) which implements much of the logic relating to hypercalls and adds sugar around these (look in tools/libxc).
The swiss army knife for administrating Xen, namely the Xen light library (libxl). This library replaces the deprecated xm tool with the xl tool and takes care of all your maintenance tasks such as starting/stopping a VM, listing all running VMs, etc. For all these operations, it works in tandem with the aforementioned libxc. (Libxl lives in tools/libxl.)
The Xenstore is a tree-like data structure from which all running domains can retrieve and store data. This is necessary since all I/O goes through Dom0 (not the hypervisor!), and domains need to communicate with Dom0 how they are going to pass I/O along. (Look in tools/xenstore.) You can inspect the Xenstore with a tool such as xenstore-ls.
the blkback/netback kernel drivers which pass the data over shared channels to the VMs. (You will find these drivers in a recent Linux kernel (e.g. >= v3.0) that has so-called PVOPS support).
Take a look at the console daemon (tools/console). Note that sometimes the Qemu console is actually used. Qemu also comes in the pictures as a default backend for if you choose a file-backed virtual storage for a VM.
Experiment with the 'Xen-way' of inter-VM communication: Grant tables, event channels and the Xenstore. With these fundamentals you can create your own shared channel between VMs. You can do this, for example, with writing a kernel module that you use in two domains to let them talk to each other.
I can also give some pointers in the source that you can check out:
xen/xen/include/public/xen.h will give you a list of all the hypercalls with comments what they do.
xen/xen/include/xen/mm.h gives you an introduction to the different memory terminology used by Xen (i.e., real versus virtualized addresses and page numbers). If you don't grasp these differences, then reading the hypervisor code will surely be frustrating.
xen/xen/include/asm-x86/config.h gives an overview of the memory layout of Xen.
xen/tools/libxc/xenctrl.h exports a large list of interesting domain control operations, which gives an abstract view of task division between Dom0 and the hypervisor.
Last but not least, the book 'The Definitive Guide to the Xen Hypervisor' by David Chisnall comes highly recommended. It covers all these topics and more in a thorough, technical fashion with plenty of code examples.
The Xen wiki and developer mailing lists are also a great resource for understanding Xen.
If you have a more specific question, then I can give you a more specific answer.
Here are few links which will guide you with ZEN Start up.Hope they will be useful.
http://www.howtoforge.com/howtos/virtualization/xen
http://wiki.xen.org/wiki/Category:HowTo
http://wiki.debian.org/Xen
For me, that is the best and more concrete tutorial with examples and step by step to start. I used it when I started.
Then you can read a lot more on Xen documentation itself or some books but as a starting point that allows you to easily install and test Xen, I choose that tutorial from Debian Wiki.
If you just want an overview, you may read this: http://wiki.xenproject.org/wiki/Xen_Project_Beginners_Guide.
This will introduce you to Xen hypervisor, suggest configuration to set up virtual machines, provide information about the networking and finally have details about tools for the management of virtual machines.
This documentation is to get the Xen specifically on ubuntu (Most importantly, it works!)
https://help.ubuntu.com/community/Xen
===
However, if you want to go to the next level and understand the working of Xen; Xen architecture, memory management, device management, CPU scheduling etc., I would recommend reading the book "The Definitive Guide to the Xen Hypervisor".
I have two questions:
Is there any API in Qt for getting all the processes that are running right now?
Given the name of a process, can I check if there is such a process currently running?
Process APIs are notoriously platform-dependent. Qt provides just the bare minimum for spawning new processes with QProcess. Interacting with any processes on the system (that you didn't start) is out of its depth.
It's also beyond the reach of things like Boost.Process. Well, at least for now. Note their comment:
Boost.Process' long-term goal is to provide a portable abstraction layer over the operating system that allows the programmer to manage any running process, not only those spawned by it. Due to the complexity in offering such an interface, the library currently focuses on child process management alone.
I'm unaware of any good C++ library for cross-platform arbitrary process listing and management. You kind of have to just pick the platforms you want to support and call their APIs. (Or call out to an external utility of some kind that will give you back the info you need.)
I am developing a distributed file system using Java, I cannot give many details at this moment. I need to test some things on Linux, I will use WMWare server an install Linux inside a virtual machine. Is there any difference between the simulated network card and a real ethernet interface?
I am developing a distributed file system ... I will use WMWare server an install Linux inside a virtual machine.
VMware is great for this sort of thing. There should be no difference except, as RichieHindle said, in performance, especially if you're planning to run multiple vms on the same server.
Use real hardware if you want usable performance benchmark results.
Java is it's own 'VM'... on top of a layer of virtualization in the guest OS... on top of VMware... on a virtual execution model CPU. Take a little virtualization here, add a little virtualization there, and pretty soon we're talking about some real abstraction!
From the point of view of application code, no, there's no difference.
The only visible difference might be in performance - the speed of response and exact timings of things might be different, but you're talking microseconds.
There's so much general-purpose software that works flawlessly under VMs that the answer to almost every question of the form "Are VMs different from real machines?" at the application level is "No".
(Things might be different if you were talking about kernel-level driver software.)