Issue
All the drivers in the Linux running in the same context (address space of the kernel-space), or each in a different (similar to how the different processes work in a different address spaces in user-space)?
Solution
In x86-Linux, 32 bits, all drivers run in so called kernel mode (sometimes called Ring 0 mode because of the way Intel organized its CPU protection scheme).
When a driver is called by a process (say, you issue for example an read() system call to a device driver), there's a function inside the driver that gets executed. That function is said to be executed in that process's context.
What this means is that the driver function executes within the memory map of the calling process. This implies that the driver function can access not only its own variables and structures stored in the kernel reserved addresses (virtual address 0xC0000000 and up) but can access variables and code of the user calling process. This allows functions like copy_to_user() or copy_from_user() to be able to interchange information with the user calling process.
Recall that the memory map of any process in Linux has two parts: one big part of a maximum of 3GB of memory available to the user process. This memory is private for that process. Another part of 1GB is for the kernel. This part is shared among all user processes' memory maps. The code, stack and global variables of a driver resides within this 1GB space.
There's another context: the interrupt context. A Linux driver can install a handler for a hardware interrupt. When this interrupt is triggered, the handler is executed, but this time, it will execute in the context of whatever process was being executed at that moment (i.e. the handler has not been called from an user process)
A typical driver is then a collection of functions, the majority of them are executed upon a request from an user process making a system call, so the most of the time, a driver is being executed (an instance of it actually) in the context of a particular user process (but unlike the code in the user process, the driver executes with all priviledges). Parts of the driver may be called asyncronously by other kernel functions, so they could be executing in another context, not related with the one belonging to the process that is using the driver.
Also remember that more than one user process could be using the driver, so each process executes the same code under its own context. A driver should be written so it can be reentered, so avoiding side effects.
Answered By - mcleod_ideafix Answer Checked By - Marilyn (WPSolving Volunteer)