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 8 years ago.
Improve this question
How does OS communicate with CPU?
There are drivers in the OS, ok I understand that part. OS uses drivers--> communicate--> device controller.
How does the communication happen? Does the OS touch the CPU directly with its commands, or is it using BIOS as the interface?
Let's assume that I will make my own OS. Its only task is to send arithmetic operations to the CPU and print results to the screen.
I will tell the CPU to put memory words to registers, count them, and then put them back to memory. How can I do that?
The CPU just runs instructions from memory starting at some offset and then keeps fetching the next instruction and repeating. The bootloader sets up the CPU to start running the OS entry point when your computer starts. Actions like keyboard or mouse input cause interrupts which the interrupt controller use to lookup special code setup by the OS to handle these interrupts. These interrupts are also used to allow the OS to switch which thread is currently running on the CPU using special privileged instructions that can only be run in kernel mode. The interrupt causes the CPU to switch to kernel mode before calling into the OS interrupt handler code so that the OS can use the necessary privileged instructions for controlling various behavior user mode code is not allowed to.
There are a lot of details concerning what registers are used for what purposes and much much more but it would take a whole book to cover everything.
Here is a free book that covers many details at a relatively introductory level.
CPU calls OS for specific tasks using interrupts, and OS uses special privileged CPU registers to program CPU.
For example, when you press key on keyboard, interrupt is generated by hardware. CPU calls interrupt handler function (it is part of OS), which will handle keypress and, for example, pass it into user program.
Other example of frequent OS-CPU interaction is task switching. Most OS uses hardware timer to generate around 100 timer interrupts every second. On this interrupt OS scheduler is called, and sometimes it can switch tasks by changing some CPU registers. In simplest OS & CPUs, scheduler will change SP (stack pointer) and PC (program counter) register. With more complex CPUs it will also reprogram MMU hardware unit of CPU and change many internal control registers.
External hardware usually programmed by drivers by doing PIO writes or writes to mapped PCI space (writes to special addresses of hardware memory).
Related
I'm curious about how the drivers work out of the box in x86 motherboards, like display, USB controllers etc.
For example :
Booting a toy custom kernel in x86 can display to screen without doing any extra work on the drivers space, however for an Android phone which is an embedded system, it seems almost impossible to display to screen with my own toy custom kernel (as there is information out there available about the memory map of the device and how the display is interfaced with the device).
Why is that I/O works out of the box in x86 motherboards and doesn't on embedded computers?
x86 PC firmware has standard software interfaces (a lot like system calls), either modern UEFI or legacy BIOS int 0x10 and other interrupts.
The key point is that it's not just bare-metal x86, it's IBM PC-compatible which means software and even emulated legacy hardware like a PS/2 port, VGA, and even legacy interrupt controller.
If you didn't have all this help from firmware (for the benefit of bootloaders and toy OSes), you'd have a much harder job, e.g. needing at least a basic USB-hid and USB host-controller driver to get keyboard input. The lowest level function to handle a user input
Why is that I/O works out of the box in x86 motherboards and doesn't on embedded computers?
That's not your real question. Embedded machines have working I/O hardware, they just don't come with portable software APIs/ABIs wrapped around drivers as part of the firmware.
I think most vendor's SDK comes with functions to access the I/O hardware (after maybe doing some fiddling to get it into a usable state). i.e. to write your own driver for it.
Embedded doesn't need this in firmware because it's expected that the kernel will be customized for the hardware.
Wouldn't it be better to have a BIOS or UEFI for maximum portability? Does it have any drawbacks to include one?
Yes: code size in the boot ROM, and someone has to write + debug that code. This costs time and developer salary.
No point in booting up what's nearly an OS (a UEFI environment) just to load a kernel which is going to take over the HW anyway.
Also a downside in boot time: any code that runs other than loading the kernel where it wants to be is wasted CPU time that slows down the boot. Having a very lightweight interface that just lets you get your kernel loaded, and leaving all the I/O to it, makes sense for this.
Unlike x86 PCs, there's no expectation that you can use this hardware with an OS install disc / image you downloaded that isn't specifically customized for this hardware.
It's not intended to be easy for hobbyists to play with using training-wheels APIs. Real OSes on this hardware won't use such APIs so why provide them in the first place?
I have these related questions:
Does anybody know how an OS gets to know all hardware connected on the motherboard? (I guess this is called "Hardware Enumeration").
How does it determine what kind of hardware is residing at an specific IO address (i.e.: serial or parallel or whatever controller)?
How to code a system module which will do this job? (Assuming no OS loaded yet, just BIOS).
I know BIOS is just a validation and an user friendly interface to configure hardware at boot time with no real use after that for most modern OS's (win, Linux, etc). Besides I know that for the BIOS it should not be difficult to find all hardware because it is specifically tuned by the board manufacturer (who knows everything about it!). But for an OS or an application above BIOS that is a complete different story. Right?
Pre-PCI this was much more difficult, you needed a trick for each product, and even with that it was difficult to figure everything out. With usb and pci you can scan the busses to find a vendor and product id, from that you go into a product specific discovery (like the old days this can be difficult). Sometimes the details for that board are protected by NDA or worse you just dont get to know unless you work there on the right team.
The general approach is either based on detection (usb, pcie, etc vendor/product ids) you load a driver or write a driver for that family of product based on the documentation for that family of product. Since you mentioned BIOS, win, linux that implies X86 or a PC, and that pretty much covers the autodetectable. Beyond that you rely on the user who knows what hardware was installed in the system and a driver that came with it. or in some way you ask them what is installed (the specific printer at the end of a cable or out on the network if not auto detectable is an easy to understand example).
In short you take decades of experience in trying to succeed at this and apply it, and still fail from time to time since you are not in 100% control of all the hardware in the system, there are hundreds of vendors out there each doing their own thing.
BIOS enumerates the pci(e) for an x86 pc, for other platforms the OS might do it. The enumeration includes allocating address space for the device based on pci compliant rules. but within that address space you have to know how to program that specific board from vendor documentation if available.
Sorry my English is not very good.
Responding questions 1 and 2:
During the boot process, only the hardware modules strictly necessary to find and start the OS are loaded.
These hardware modules are: motherboard, hard drive, RAM, graphics card, keyboard, mouse, screen (that is detected by the graphics card), network card, CD / DVD, and a few extra peripherals such as USB units.
Each hardware module you connect to a computer has a controller that is like a small BIOS with all the information of the stored device: manufacturer, device type, protocols, etc
The detection process is very simple: the BIOS has hardcoded all the information about the motherboard, with all communication ports. At startup, the BIOS sends a signal to all system ports asking the questions "Who are you? What are you? How do you function?" and all attached devices answers by sending their information. In this way the computer knows how much RAM you have, if there is present a keyboard or a mouse, which storage devices are available, screen resolution, etc ...
Obviously, this process only works with the basic modules needed to boot the system, and does not work with complex peripherals that require specific drivers: printers, scanners, webcams ... all these complex peripherals are loaded by software once the OS has been charged.
Responding question 3:
If you wants to load a specific module during the boot, you must:
- Create a controller for this module.
- If the peripheral is too complex to load everything from the controller, you must to write all the proccess to control that module directly in the BIOS module, or reprogram the IPL to manage that specific module.
I hope I've helped
Actually, when you turn on your system, the BIOS starts the IPL (Initial program load) from ROM. For check the all connected devices are working good and also check the mandatory devices such as keyboard, CMOS, Hard disk and so on. If it is not success, it gives an error flag to the BIOS. The BIOS shows us the error through video devices.
If it is success, the control of boot is transferred to BIOS for further process.
The above all process are called POST (Power On Self Test).
Now the BIOS have the control. It checks all secondary memory devices for boot loader of the OS. If it hit, the bootloader's memory address is transferred to RAM.
The Ram started to execute the bootloader. Here only the os starts to run.
If the bootloader not hit, the bios shows us the boot failure error.
I hope your doubt clarified...
I am not sure if there is a certain hardware requirement on the CPU for multitasking? would it possible to do multitasking on 8086 chip?
Yes and no. There are several kinds of multitasking methods and each one requires a different degree of hardware support.
The 8086 chip is capable of multitasking but only a type of multitasking called cooperative multitasking (Early version of windows, ie, 3.0 used this). How it works is every program on the system must yield control back to the operating system every so often. The operating system in turn passes control onto the next program, which then must yield control back to the operating system after some time.
There are some obvious drawbacks, what if a program never yields control back to the operating system? Then the entire system hangs and there is no way to terminate that bad program.
The type of multitasking used today is called pre-emptive multitasking. It works by interrupting each program and passing control onto another one. Programs do not need to be aware of the multitasking at all, they can be written to assume that they are the only program running on the computer, so the actual multitasking element is transparent to them. This kind of multitasking needs hardware support in the form of what is called virtual memory. The operating system needs to be able to separate the addresses spaces of each program so that each program is not directly aware of each other. Then hardware interrupt timers are used to interrupt each program so that the operating system can move from one task to the next.
Different architectures have different methods of actually doing the task switching. It's possible to do it all entirely in software with just the support of virtual memory and hardware timers, however some architectures support constructs to simplify this process, such as x86 which has the Load Task Register. This isn't strictly necessary however to implement multitasking and most operating systems that I am aware of do their own task switching.
For more information on pre-emptive multitasking and how it works in the x86 architecture, I recommend this article: http://wiki.osdev.org/Multitasking_Systems
EDIT:
The MP/M-86 operating system used what can be considered a preemptive multitasking model on the 8086 by using a hardware timer to interrupt processes and move onto the next one, so the 8086 is capable of a form or preemption; however many of the same issues raised above are still a concern. For example, each process has access to other processes memory spaces. There is also nothing keeping a process from hijacking the system by disabling the hardware timer interrupt. In order to have a robust multitasking environment a large degree of hardware support is necessary.
As far as I understand it, any program gets compiled to a series of assembly instructions for the architecture it is running on. What I fail to understand is how the operating system interacts with peripherals such as a video card. Isn't the driver itself a series of assembly instructions for the CPU?
The only thing I can think think of is that it uses regions of memory that is then monitored by the peripheral or it uses the BUS to communicate operations and receive results. Is there a simple explanation to this process.
Sorry if this question is too general, it's something that's been bothering me.
You're basically right in your guess. Depending on the CPU architecture, peripherals might respond to "memory-mapped I/O" (where they watch for reads and writes to specific memory addresses), or to other specific I/O instructions (such as the x86 IN and OUT instructions).
Device drivers are OS-specific software, and provide an interface between the OS and the hardware.
A specific physical device either has hardware that knows how to respond to whatever signals from the CPU it monitors, or it has its own CPU and software that is often called firmware. The firmware of a device is not specific to any operating system and is usually stored in persistent memory on the device even after it is powered off. However, some peripherals might have firmware that is loaded by the device driver when the OS boots.
There are simple explanations and there are truthfull explanations - choose one!
I'll try a simple one: Along the assembly instructions, there are some, that are specialized to talk to peripherials. The hardware interprets them not by e.g. adding values in registers oder writing something to RAM, but by moving some data from a register or a region in RAM to a peripherial (or the other way round).
Inside the OS, the e.g. the sound driver is responsible for assembling some sound data along with some command data in RAM, and the OS then invokes the bus driver to issue these special instructions to move the command and data to the soundcard. The soundcard hardware will (hopefully) understand the command and interpret the data as sound it should play.
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.
What are the characteristics of a multitasking operating system?
What makes it multitasking?
Are there non-multitasking operating systems?
What are the characteristics of a multitasking operating system? What makes it multitasking?
Multitasking operating systems allow more than one program to run at a time. They can support either preemptive multitasking, where the OS doles out time to applications (virtually all modern OSes) or cooperative multitasking, where the OS waits for the program to give back control (Windows 3.x, Mac OS 9 and earlier).
Are there non-multitasking operating systems?
Any OS that only allows one thing to be done at a time (DOS for instance).
A multi tasking operating systems is:
An operating system that gives you the perception of 2 or more tasks/jobs/processes running at the same time. It does this by dividing system resources amongst these tasks/jobs/processes. And switching between the tasks/jobs/processes while they are executing very fast over and over again.
Yes there are non multi tasking operating systems, example: commodore 64's OS (Commodore BASIC 2.0). Probably some custom made software for some companies. Perhaps like an ATM machine, or movie theater stub ticket system.
A multitasking OS is able to manage various processes side-by-side. One particular ability is the sharing of CPU time among the processes.
Yes, there are plenty of non-multitasking OSs. Back in time, they were the rule: MSDOS, for example.
From the dinosaur OS book ("Applied operating System Concepts"):
Time sharing, or multitasking, is a logical extension of multiprogramming. The CPU executes multiple jobs by switching among them, but the switches occur so frequently that the users can interact with each program while it is running.
Timesharing/multiasking is a logical extension of multiprogramming.A multi-tasking os allows multiple jobs to be executed simultaneously by switching amoung them.Usually CPU process only one task at a time but the switcthing is so fast that it looks like CPU is executing multiple processes at a time.
I'm not sure if you're supposed to ask your homework questions here... ;)
A multitasking OS allows you to run multiple processes (tasks) "simultaneously". They do not actually run at the same time, of course, since there is only one CPU. What happens is that one process runs for a while, then the OS breaks in (through an interrupt), stores away the state (context) of the current process, restores the context of another, and allows that other process to run for a while, etcetera.
MS-DOS is an example of a non-multitasking OS: as long as you're playing Commander Keen, no other tasks can run on your computer (including the DOS shell itself).
A (preemptive) multitasking OS is able to run more than one process simultaneously and has control over which process is using the CPU and other resources at each time, as opposed to a cooperative multitasking OS where the processes had to voluntarily relinquish the CPU, leading to hangs and crashes.
Usually, modern multitasking OSs also provide memory isolation between processes and support different security levels, allowing OS code to do things user code cannot.
A Multi-Tasking Operating System would be an OS that allows for the simultaneous execution of multiple (more than 1) processes. Operating Systems that you are used to, like Unix, Windows and OSX are multi-tasking operating systems.
An example of a non-multi-tasking operating system would be MS-DOS. Although you could get multiple processes to run simultaneously under MS-DOS, with the help of Windows 3.1 or Windows 9x, the OS itself was non-multi-tasking.
For more information regarding Computer Multi-Tasking you may want to check out the wikipedia page: http://en.wikipedia.org/wiki/Computer_multitasking
Wikipedia has a pretty good lowdown on multitasking.
There's a popular non-multitasking OS that's not been listed yet: PalmOS.
It's just an illusion for the user that parallel working is done, but not exactly like this.
A multi-tasking o/s is an o/s that allows a user to simultaneously run various tasks at the same time. Actually it is not so because there is only one cpu. The concept behind this is time sharing. The operating system divides cpu time among various tasks, but this time is very small (nanoseconds) that the user feels that all programs or tasks are running simultaneously.