So I'm confused on how exactly we as the programmers talk to devices on the computer. Now I'm not talking the big ideas. I know that there are device drivers that sit atop the hardware so that different programs can use there features.
But in general who exactly talks to the drivers? Is the programmer writing the application responsible for calling a function on the driver? Or does the programmer call a function through the operating system which then handles the call to the driver? As you can see I'm really just confused about the nitty gritty of how the driver, OS and your application fit together.
The application doesn't call the driver directly - that would violate the entire idea of user mode and kernel separation. Instead the OS exposes the relevant ABI to the user mode programs, enabling the applications to call the exposed functionality (with respect to the predefined restrictions that should be documented).
Related
I’m on process of developing my own Operating System based in Linux.
This week we’re aiming to implement very simple USB device driver , which is quite hard to get basic algorithm .
However commonly it’s hard to find out some sources aside from commercial linux system.
And I want to get some advice about this .
Plus, I do all these stuffs on Ubuntu , using QEMU emulator.
I’ve done simple file system and hard disk device driver so far.
Help me out how to implement USB device driver with very sime ideas.
Thank you !! :)
Implementing USB is quite the task. First you must have a working PCI(e) enumerator or other form of finding the USB controller. You then must find out which of the four most common controller types it happens to be. Each controller type is completely different from the previous and must contain its own driver. You also need a standard USB interface that is independent of the controller type.
Taking on the USB is quite the task, but in my opinion a very interesting and enjoyable task. Enjoyable enough, that I even wrote a book about how to do it. It explains how to find the controller(s) via the PCI(e) bus, how to setup this bus, how to detect the type of USB controller--UHCI, OHCI, EHCI, or xHCI--and how to send and receive data packets to/from attached devices. This book was written exactly for the purpose of those of us creating our own operating systems and adding USB support to them. The fact that you are basing your OS on Linux should not matter since the book does not rely upon any existing OS to accomplish this task, other than the example programs relying on memory allocation, which is easily modified for your developing platform.
Might I say that if you do take on this task, it will be a difficult task, but it will be an enjoyable task. In my opinion, the USB is the most enjoyable part of this hobby of ours.
If I know the device's model or vendor. Is there any direct way by which I can know the operating system of this device (e.g through the device driver or something like that? ). For example, I will quote an answer for a previous question I asked in: What is the difference between the firmware and the operating system?
Someone have said:
Hardware vendors commonly use a derivative of linux (e.g. Cisco IOS)
How can I know this. I know a name for one cisco device but I do not have the device and I need to check what is its operating system (even if it is widely known that it is Linux, I need to check this myself). How can I get this piece of information ? I checked the companies site and google, and I can not find any answer.
If the terms of the GNU Public License are complied with, it should be reasonably clear if a device is using any GPL code, including Linux, moreover the source code should be available too.
If the device uses an OS that is not open source, then even if the information were available to you, it is unlikely to be particularly useful except perhaps in respect to applying manufacturer's firmware updates.
Linux is by no means that common in embedded systems in general. It is commonly used in certain types of device, such as routers, STB's and NAS's. Often these devices have a web-server interface through which version information is usually available, but there is no common method of accessing this information, you'd have to access the particular URL for the device and parse the HTML.
You need a serial cable to hack into the device or read the binary from the flash and examine the hexdump. I have a STB in my home. The provider doesn't reveal the OS. There are competitors out there who need such information to take you down.
I'm currently doing a course about Operating Systems.
I understand that a kernel is a core part of an operating system that acts as a bridge between user applications and the data processing elements of a computer such as the CPU.
Why do we need Drivers then (e.g Touchpad drivers), doesn't the kernel control all computer hardware?
Because there are literally thousands (if not hundreds of thousands) of companies that produce hardware devices. The Operating System company cannot write software to handle all of them, so they provide a generic programming model using which those hardware companies can write software that could talk to their hardware.
Important to note is that although drivers are not actually part of the kernel as such, they do have some low-level privileges (direct access to hardware) because their code runs in Executive mode, unlike normal applications which run in User mode and generally do not access hardware directly. The whole point is that once the OS provides a way to write hardware-controlling software (called drivers), any vendor or person is free to write a software that could take advantage of the specialized features of their/his hardware device.
Also note that some hardware devices follow well-known standard (such as keyboards, mice, many video drivers, monitors etc.) and most OS come with built-in support for those devices. On the other hand, some devices do not have or follow standards, while still other can have both kinds of features, i.e. a subset of features that could be accessed by the default driver, plus a subset of features that doesn't follow any standards and thus is not supported by default driver. In all such cases, hardware manufacturers supply their own driver that knows the ins and outs of their hardware and therefore can take advantage of all features efficiently.
Certainly kernel does control all the hardware. However, there are way too many different hardware devices out there.
To deal with this vast variety of different devices, developers write specialized modules - and these are called drivers.
Recently, I'm trying to write a simple OS. This is a big project.
when I'm writing my code, I'm wondering how modern OS contact hardware under protected mode
In real mode, we can just call the bios interrupt to accomplish this job.
But I'm wondering how to accomplish this goal in protected mode.(Is it using in and out instruction??)
I traced some of the linux source code, but still can't find the appropriate code.
I know it is a basic question to many people, plz help me, tks.
and sorry about my poor English.
In protected mode, the CPU can run in either kernel mode or user mode. In kernel mode, you can always access the hardware. Calling BIOS interrupt is one old method, but a modern OS normally has its own device drivers for the hardware and does not call BIOS too often. If you know the hardware datasheet, you can use in, and out to access the hardware directly. Also, for modern PCI and PCI Express devices, they supported memory mapped IO (X86 CPU also supports this), and it means you can use mov to access the hardware.
For x86, the CPU also allows the user level program to access the hardware using in and out instructions. You can find it on Intel CPU manual. Just set DPL, CPL? (I forgot the correct name).
I guess you'd better read some book about device drivers, such as Linux Device Drivers, 3rd edition. http://lwn.net/Kernel/LDD3/
Someone told me that for most operating systems, the drivers become a part of the kernel. How does this happen? Does the kernel decompile itself, add the driver, and recompile itself? Or are the drivers plug ins for the kernel? Are drivers even their own separate programs?
I'm going to answer this even though it was asked 7 years ago for those who stumble on it all these years later.
The Kernel is the heart of the Operating System and thus includes support for a wide-variety of functionality which will be relied on system-wide.
The System Service Routines do not have to be present under a single kernel image (e.g. on Windows, there's FltMgr.sys to handle the Filesystem, and this is communicated with through device control routines).
A kernel-mode device driver is in layman's terms, an extension to the kernel. You'll be executing with a Current Privilege Level of 0 (which is for Ring 0) and thus the restrictions on memory access and usage of specific instructions will be revoked for you. Your trust level will also be better.
A kernel-mode device driver will essentially be a "module" to the kernel. You have a Dynamic Link Library (DLL) in user-mode on Windows, or a Dylib on OS X... Think of a kernel-mode device driver as the kernel-mode equivalent, except it doesn't have to be about extending the actual kernel, it can be for functionality which must be implemented at a kernel-level for an third-party application.
Furthermore, the idea behind it is that the main kernel is able to provide access to a set of APIs for the third-party kernel-mode software to rely on. Otherwise, the third-party developer would have to implement literally everything themselves, and that would basically be "OS development".
Bullet-points:
Kernel-Mode device drivers have the same privileges as the actual OS kernel.
Kernel-Mode device drivers are supposed to have the ability to use some of the OS kernel's APIs to assist with implementation of functionality which works with how the OS was designed (e.g. Filesystem, Process, Registry (or equivalent), memory management, etc.).
Kernel-Mode device drivers are basically an "extension" to the OS kernel because you are not replacing the actual kernel but you're also at the same privilege level (mentioned as #1) and could theoretically extend system-wide functionality if you felt like it (e.g. add support for user-mode software to rely on the device drivers functionality through communication methods like call gates or Inter-Process Communication).
I hope this somewhat helped any future stumblers of this extremely old thread; the question was really good.
A driver is compiled into a library that exposes a known interface. The kernel then scans for drivers on startup and loads them into kernel memory. Some operating systems, such as linux, also support kernel modules that can be loaded / unloaded while the OS is running...